Build your backend in the @pragdave style and you can have your web app not using an API, be it REST or GraphQL, and have the mobile app using the GraphQL or REST API. So, basically you will want to have a clear separation of code that is specific for web requests, from the one that is specific for API requests, and have both talking with a core that is agnostic from the transport layers being used to talk with the client, aka the web app or mobile app.

As someone who works in API security I can tell you that I would avoid as much as possible to use them from a browser, because in web apps you are better in terms of security by not using them.

APIs are very hard to truly secure, aka to lock-down only to clients you want to allow access to it, aka the clients you have coded, by other words genuine instances of your web app and mobile app. You can tell me that you use API-Keys or any other fancy mechanism, like HMAC, and I can tell you that all of them are not that hard to bypass by a de-terminated attacker.

So I have a question for you:

Do you know the difference between WHO and WHAT is communicating with your API server?

In my experience developers of any seniority are often not aware of this difference or they have a misleading understanding of it.

I recommend you to read this article I wrote where I explain it in detail, but it can be resumed as:

The who is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.

The what is the thing making the request to the API server. Is it really a genuine instance of your mobile app, or is a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?

So, think about the who as the user your API server will be able to Authenticate and Authorize access to the data, and think about the what as the software making that request in behalf of the user.

You can also look to other articles I wrote that go into detail about extracting API keys for reuse outside your mobile app:

TLDR:

In order to help to demonstrate how to steal an API key, I have built and released in Github the Currency Converter Demo app for Android, which uses the same JNI/NDK technique we used in the earlier Android Hide Secrets app to hide the API key.

So, in this article you will learn how to setup and run a MitM attack to intercept https traffic in a mobile device under your control, so that you can steal the API key. Finally, you will see at a high level how MitM attacks can be mitigated.

While we can use advanced techniques, like JNI/NDK, to hide the API key in the mobile app code, it will not impede someone from performing a MitM attack in order to steal the API key. In fact a MitM attack is easy to the point that it can even be achieved by non developers.

https://blog.approov.io/how-to-extract-an-api-key-from-a-mobile-app-with-static-binary-analysis

TLDR:

The range of open source tools available for reverse engineering is huge, and we really can’t scratch the surface of this topic in this article, but instead we will focus in using the Mobile Security Framework(MobSF) to demonstrate how to reverse engineer the APK of our mobile app. MobSF is a collection of open source tools that present their results in an attractive dashboard, but the same tools used under the hood within MobSF and elsewhere can be used individually to achieve the same results.

Using MobSF to reverse engineer an APK for a mobile app allows us to quickly extract an API key and also gives us a huge amount of information we can use to perform further analysis that may reveal more attack vectors into the mobile app and API server. It is not uncommon to also find secrets for accessing third part services among this info or in the decompiled source code that is available to download in smali and java formats.

The lesson here is that shipping your API key or any other secret in the mobile app code is like locking the door of your home but leaving the key under the mat!

Regarding web apps an attacker just needs to hit F12 and search for the API key and extract it to use it in automated attacks against your API.

I can continue and go more deep in other scenarios that can be used to attack your backend, but I don’t want to overwhelm you, but if you are interested in learning more about different scnerarios you can always look for my answers on the security questions at StackOverflow:

Tip: Just click in the security tag on my profile to see all my answers to security questions.

It is a common question, and has been asked already, You might find some related topics.

e-commerce site does not require a lot of concurrency, and Shopify is made with Rails. Unless You use concurrency. Live stock update, bid and auctions etc.

I advise You to start by adapting this book to latest Phoenix, You will learn how to make a shop

https://shankardevy.com/phoenix-inside-out-mpf/

Once done… You can add graphQL

I do not think you should generalise like that. My consultancy at (https://www.amberbit.com) has clients that are e-commerce sites, some really big and high-traffic. There is plenty of concurrency and OTP comes in exceptionally handy.

I am not involved coding-wise in either of these projects but from what I hear from my employees, they are doing a lot of data sync (in and out) with external services. Think, delivery services, currency conversion, payment systems, shipment tracking, stock management software. There are streams of data to process, and things like GenStage come in handy. In other places they benefit a lot from implementing circuit breakers as failsafe mechanism when something external fails, also exceptionally easy to do with OTP primitives.

As far as I can tell, they are not using LiveView, however, and that would probably not necessarily be a good match for everything as the number of requests they handle is huge, and statelessness of HTTP here is a possible advantage. You don’t have to keep track of all these connections once product page is served. It may be, very much useful to employ LiveView, however, on things like registration, or checkout process, something that I believe they are doing heavily in JavaScript.

I am also a big fan of GraphQL, but again, this is not something we use with e-commerce clients. Again think of product page, you probably want it server-rendered, served as fast as possible and as simple as humanly possible to be properly indexed by various bots (Google, Facebook etc.). As far as I understand the need for GraphQL is limited in the e-commerce store scenarios I saw.