How to host a common back-end code of Firebase for React and React-native without compromising the real-time feature? - express

We (me and my team) are building a food delivery real-time Web and Mobile app (using react-native) which also includes payment integration and admin dashboard for a client.
The tech stack we've chosen for the app:
View
React (Web app)
React-native (Mobile app)
Back-end
Express
Firebase
We thought of sharing the app data using a common back-end for the web and mobile app. Basically, we would've created an API that provides the end-points using Express and then Express would Save/Retrieve data to/from Firebase. Express would be our middle-ware.
We created 2 project folders keeping first of all only web app in mind:
react-webapp
express-webapp
And then, we start the respective server for the packages.
Unfortunately, API's aren't real-time and we may have to implement our mechanism to make the flow real-time.
So, we switched to merging firebase with react. We decided that'll use express just for sending emails. So, the folder structure for the web app is something like:
react-webapp
node_modules
public
src
firebase
With this approach, we created a demo and we do get real-time updates and we can also use ReactFireMixin. Later we can use the same folder and add it to react-native as well for Saving/Retrieving data from the database.
My question is, as we don't have any prior experience of building a Web and Mobile app with a common database/back-end and React/React-native, is this approach apt? Is there anyway in which we can segregate the front-end code from the back-end and utilize the real-time feature of firebase?
The reason for segregating the backend from front-end is to keep a common real-time backend for react and react-native without having to keep 2 separate firebase folders for the web and mobile app.
Note: If you are wondering why real-time then the client has asked for a real-time order placement mechanism.

It may work to use socket.io with express to allow for realtime back end updates that come from firebase.

Related

What is the difference between an Angular or React frontend with an API backend and a frontend with a headless CMS?

I don't understand the difference between creating an application with Angular or React (or something else) on the frontend and communicating with an API for the back (and call it a CMS), and a Headless CMS. They sound the same. What is the difference?
An API is a way for software to communicate with other software.
A headless CMS is a content management system that comes with an API for clients to retrieve data and doesn't come with its own end-user frontend (they generally come with admin frontends).

Can I use NextJs API routes to handle both web and mobile app?

I want to create web app in Nextjs and in the future mobile app in React Native. But I am confused what api to use. Do you think that the Nextjs api can handle both web and mobile apps? Is this possible and is it good idea at all? Should I use PHP backend for that? Thank you very much.
With the assumption that you are talking about API Routes :
I would ask you that you think through the scale of your web and app. If this is a simple web/app that you do not expect to grow much - The NextJS API which is similar to standing up an nodejs express server is not a bad option.
Remember a few considerations when designing this API
You may have to distinguish the request origin (web/app)
CORS may have to be customized - Next exposes this
You could set an app specific route to ensure isolation or use headers to distinguish behavior if your application bifurcates in the future.
These concerns are shared even if you made a PHP, ExpresJS or any other API middleware.
Once you are past all this, i would ask you to consider
Using a GraphQL server like Apollo that works nicely with Next and is custom built for this purpose..
Evaluating API Gateways for security and scale.
You don't use any external tools at all.
Next JS has serverless model. So, you don't need to mess with BE.
You can create a number of API routes you want. in /pages/api folder. You can even split like /pages/api/desktop and
/pages/api/mobile folders.
You connect your database (MongDB, sql etc) via /middleware/your_file.js. Here is example for MongoDB
If you like, you can even add some security (ex: Auth0, next-auth
etc) to secure your API routes created in /pages/api folder. Example for Auth0
After, you can access you data througth API calls. Very good!

Next.js API is back-end?

I know Next.js is front-end but when i used API of next.js it can response and can manage route or anything about back-end can do.
Then i want to know "Next.js api is back-end ?"
Yes. Next.js is a pre-rendered React app in the client-side that users can view and interact with and can be considered as front-end. At the same time, it also does server-side rendering and API routes which can perform server-side code and access data in the database and can be considered as back-end.
Next.js > v13 uses two folders app or api for Dynamic Routing. Store React components in app for client-side or server rendered components. The backend functions or server-side of Next.js is with the api folder. The api JavaScript code is not executed in the browser but with Node.js so this is not safe for static page generation. When Next.js is hosted in the cloud with Vercel then your server-side or serverless JS will render, but on Netlify or other static hosts the api folder will be ignored or throw errors. It's like running Express.js code in the browser the JIT rendered will fail
Next.js v13 transitioned React folders from pages to app and currently supports both folders. Before v13 the React client code was stored in pages only.
Next.js api provides REST API. We are sending requests internally to our next.api routes. With this you can add business logic in your next.js project without writing any additional custom server code and without configuring any api routes. In node.js app, we need to separete api code into controllers and routes, then register each route in express app, then you need to make sure that you registered the routes in correct order.
The only drawback as of now, vercel does not support websocket connections. So you cannot have realtime services. But you can kinda make it almost realtime with SWR. More on SWR Basically, with swr, you tell next.js to fetch data periodically, keep the response in cache and serve it.
With this feature, Next.js provides everything to build a full-stack application. So next.js also simplifies the backend for us.
Yes. Next js is framework of React js. you can use it both like- frontend and backend. Thanks.
I come from the asp.net world and am slowly, enjoying, learning javascript development. It does clash with me though when people describe something like Next.js, which I'm enjoying learning, as a backend.
To me it is more conceptually like an asp.net server-side frontend (Webforms, MVC, Razor Pages) etc. It seems its main concern is producing reactive frontend UI. Just because some of the frontend functionality runs/processed on server does NOT make it a backend AT ALL.
What about the fact it has api endpoints?
Well to me, a web api is only a means of enabling a frontend to talk to a backend across a network, the internet in this case. For me an api handles only very limited concerns; provides the endpoints, handles de/serialisation, talks http to the caller and that's kind of it, thin and dumb.
The backend doesn't really start till you get to your App layer and then the architectural fun can start, Application orchestration, Domain logic, dependency inverted data access layer etc. etc. all the things that talk to the complexity of designing robust software.
So much talk seems to be focused on where bits sit, is it on the client, is it on the server and less about the concern of what goes where.
I thing Next.js is an excellent server-side, frontend framework but whatever your onward stack into the backend, it's not a backend!
Your Question: "Then i want to know "Next.js api is back-end ?""
Simple Answer: It depends
For any technology to be a backend it must fulfill its minimum criteria to identify itself as a backend.
If you don't use NextJS features and use it as a frontend, it behaves as a frontend.
But you can use it as a backend if you want to use that way.

Building an API and Desktop app with electron

Is it possible to build an electron Desktop app frontend and API within the electron platform without having to separate the api and the Front end. I am doing this to avoid having to ask users to install two files.
Yes, you could potentially wrap an API server and a frontend into a single Electron application.
Essentially your server could be spun up within the main process. Then you could use your frontend/renderer process to make calls to your API similar to a website.

Shoutem - How does it work for custom backend/integrations?

Interested to learn more about the product. The frontend seems very straightforward. What I'm curious about is how much "backend" services your tools supply? For features that you run the backend for, is there API access?
This is the use case I'm trying to understand. If we were to sign up as an agency, would we be able to 1) create an app with your system 2) add custom features/native modules/etc and 3) connect that app to a custom dashboard which we run ourselves
From the backend services, Shoutem has its own Cloud Storage to manage your data in the app and Automated app publishing tool for publishing your app to both stores. You can customize Shoutem Cloud with your data models.
To answer other questions:
Yes, everyone can create their app on Shoutem.
Shoutem is just an architecture on how to create React Native apps. Apps are divided into smaller building blocks, called extensions. This architecture enables developers to reuse extensions in multiple apps which leads to more efficient app development process. You can build your custom extension and that extension can use any feature from React Native,
including native functionalities. We made sure not to restrict you on how you can use React Native.
Our extensions are by default connected with Shoutem CMS. Since they are open sourced, you can customize them to use your own backend instead. For your own extensions, you chose which dashboard they are going to use.
Extensions are built from 2 parts: app part and server part. App part represents application logic, while server part allows the customization of Shoutem Server including Dashboard and CMS. For Dashboard, you can write Settings pages which can be hosted anywhere, including on your own backend.
All the underlying concepts are explained on Shoutem's Developer portal: shoutem.github.io