I just started using nx.dev to migrate from a single app repo to a monorepo as I have added a very basic static documentation app to the mix which is deployed to a subdomain docs.company.com.
My main application is currently deployed to main route company.com. However, one could think of it as different apps as well where there is app1, app2 and admin for example. I do like the idea of having everything as a single application as it can be easily deployed with nx and Vercels monorepo support.
I am just not sure what the go to approach is here. Of course, I could split up the main app into multiple apps and deploy them independently to subdomains such as:
admin.company.com
app1.company.com
app2.company.com
If understood correctly, I could also use multi zones support if I do not like subdomains and use one domain instead.
This main app, that could logically be split up in multiple apps is non public and authentication is required. It is completely client side rendered while apollo client is used to interatct with the GraphQL API. This API server also sets an http-only JWT cookie for authentication. I am quite sure I could mitigate the issue with subdomains in this regard by setting the domain cookie setting, such that the cookie is also valid for subdomains.
However, as the cookie is http-only I cannot access it from the client and need to keep track of the logged in status in my global state mangement (which is overmind.js). Splitting up the app would add some extra complexity to persist global state between subdomain apps.
I am not sure whether this is worth it or if it is better sticking to the one app approach. I would love to hear your opinion and maybe I have forgotten some major issues. Some questions that come to my mind:
What are the advantages and disadvantages of using subdomains?
Is it more preferable to use multi zones and only one app?
How could the auth/global state issues be solved if switching to multiple apps?
What are your thoughts?
Related
My website will perform CRUD operations and will work with MongoDB and Firebase storage+auth.
What are the reasons / advantages to developing a separate Express server instead of integrating everything in my next.js app?
As far as I have seen, it can all be done in my next.js app, but I still see many projects working with a separate server.
Depends on what your app does and how you are hosting it.
Running Next.Js on a standard server will be of little difference whether you are using nextjs's /api or expressjs.
However if you are hosting on serverless (e.g. Vercel), I would recommend using a separate express server if you have alot of CRUD operations because the warming up of serverless is really bad user experience.
Build and Deployment
Next/JS - If you want to edit something on the backend, and push the changes, it will require you to build the entire JS app, and depending on how big is your app, it can take alot of time (especially if alot of static generated pages).
Express - If you running express separately, you can build and deploy front end and backend separately. It's time saving, and you can also better organise your codes frontend/backend.
Choice of deployment
I have a choice to take advantage of Vercel to host my frontend, with static generated pages and some server side generated pages (automatic scaling, caching, CDN etc), and host my backend with a separate cluster of servers.
PS: I moved from single Next.JS app to NextJs+Express
I can think of a few things why they would have a different server from the one NextJS provides:
Familiarity with Express, Koa, etc. All next-connect helps with this
There is an already existing API in PHP, Express, Flask, etc.
It is literally based on what you would want to do, the extra interactions with MongoDB & Firebase would be same on both the technologies, unless you want to isolate respective things separately, I don't see any harm in doing everything together on next.
Given that the idea of using next.js, as per my understanding would be to utilise server side rendering.
I've been using Next.js with Typescript for quite a while now and I, as of now, have found one reason not to include express.js in my project. And the reason is Vercel.
Since I use Vercel for continuous deployment of my projects, and Vercel Not supporting any custom server as of there Docs here, I refrain from using Express or any other custom servers.
I didn't face any problem performing CRUD operations with MongoDB, can't say about firebase.
On Next.js Docs, I found these points to be considered:
A custom server can not be deployed on Vercel, the platform Next.js was made for.
A custom server will remove important performance optimizations, like serverless functions and Automatic Static Optimization.
But at the end of the day it very personal opinion weather to use a custom server or not. It might depend on a very specific use case you might be looking for.
Personally, I try to keep it to just NextJS, but if I have to manage real-time data with Socket.io, I get a separate server because other than WebSockets, serverless functions can do everything else.
Here is a question on how to structure a web app based on react.
We are planning on deploying the front-end of an app that will contain several parts like main part, a customer account part and say a backoffice part for the company staff to track customer's data etc...
The plan is to deploy this app on Netlify and use subdomains like example.com, backoffice.example.com and clients.example.com.
My question is: shall we use a single React app to handle these 3 parts or use 3 different React apps ?
Initially we thought using 3 different apps would be better in terms of maintenance and evolution but any professional feedback with pros and cons would be appreciated.
Thx a lot.
We do something similar (but with Angular). It works well as each of the teams is responsible for their own app as far as maintenance and release cycles is concerned. It is pretty scalable as well - no problems to just keep adding new apps (as we are doing).
We have the whole lot behind NGINX, and so in the code we can just refer to simple paths like /client-services, /marketing and /sales - i.e. no server/protocol configurations.
You need to keep the following in mind :
How the apps interact with each other i.e. a standard data object, or cookies/localStorage
Authentication
You will be using app/internal routing for modules within your app, and external routing to redirect to other apps
We've been burnt before with one monolithic app...
This is the first time i'm working with firebase. My goal is to have a bounch of client apps (more and more over time), all of them managed by an admin app (One app to rule them all).
The thing is that the client apps have a certain content that needs to be updated from the admin app. My best approach is to create a firebase project, put the admin app there and adding client apps over time. I'have read that is possible to have an unlimited number of apps inside one Firebase project. On addition, someone told me to create one project for each client app and connect them to the same database somehow. I simply don't know what to do.
Which would be the best solution for my problem? thank you
firebaser here
A Firebase project can currently contain up to 30 app definitions. This is meant to support variations of the same logical application. For example, having an Admin app in addition to the app for regular users, and/or having an iOS, Android, and Web version of the same app, and for example having a free and a pro version of the app (if that is allowed by the stores where you deliver them).
Adding multiple apps to a project is expressly not meant to be used for white labeling apps, where you ship essentially the same app with different branding to different user segments, as you'd be sharing the backend services between them. For some backend services (such as database and storage) this is not necessarily a problem, as you can isolate the customers with security rules. But for other services (such as authentication and analytics) this is not possible, which is why this use-case is not supported.
If you need to define a separate app in the project for each customer, the only supported approach is to create a separate project for each customer.
I'have read that is possible to have an unlimited number of apps inside one Firebase project.
In that case please provide a link, so we can either fix it, or (if it's not in the Firebase documentation) leave a comment to clarify.
I have two frontend apps. First one uses Static Generation (for SEO purposes), and the Second one uses Client Side Rendering (for all stuff behind auth flow).
I want to have both of them under the same purchased domain, with the base endpoints to be something like:
mydomain.com\public\* : for all my public facing statically generated content using the first App.
mydomain.com\auth\*: for all the stuff that lies behind the auth flow.. made using the second app.
So the question is:
How to map these two separate apps to two base endpoints under the same domain? I was reading this post Share an API Endpoint Between Services, but it seemed to be for the backend.
In case anyone is interested to know why two separate apps:
It's because the Static generation is done using Next.js, while the Client side stuff is done using simple create-react-app. This post explains why this combination needs to be separately deployed.
Refer to this
Create two separate s3 buckets for your NextJs and React app. Attach them to a CloudFront distribution. Attach a lambda function to your CloudFront distribution and route requests to different origin based on whether the request.uri.startsWith('/public') or not.
I've picked up Angular and am now developing two separate applications, the frontend, Angular app, and the backend, the Laravel app.
As of now my backend app is just an API endpoint that handles requests, database interaction, logic, validation, etc.
However, what stops someone from requesting /api/users/1 and getting that data?
Right now there is nothing in place that prevents this from occurring.
What's the best way to prevent this from occurring and verify the request is sent through the application and not through something like http://hurl.it from some random user?
You should first evaluate what routes need to be protected, and who should have access. Sometimes it might be fine to leave them open to the public.
Once you've figured that out you have a few options. I personally lean towards the oAuth 2.0 protocol. Some people find it to be over kill. Then there is also WSSE, I personally feel like today there is far better resources explaining the use of oAuth and would probably be easier to follow.
You can google around for oAuth server libraries for laravel. One such is: https://github.com/lucadegasperi/oauth2-server-laravel
You will also probably want to enable CORS if your angular app is on a different domain from your api. IE: api.example.com (holds api). And example.com is where your app lives.
For CORS laravel also has some packages, one such being: https://github.com/barryvdh/laravel-cors