I am working on a SAS product. So there could be 1000 users using my application at the same time.
Technologies Used:
Django for Backend
React.js for frontend
Django Rest Framework for APIs
I have hosted this project on a server with customized Nginx settings as shown here: https://stackoverflow.com/a/60706686/6476015
For now, I am having no issues but I want to know if there is some possibility of something going wrong in the future as usage and data will increase. Should I host the frontend and backend on separate servers?
Related
I'm developing an app that contains next.js as a frontend and separated backend server running on express. I'm wondering about production deploy and costs, I did some research but I'm not sure what's the best way to do it.
My folder structure is following. I have separated packages.json on the frontend and separated on the backend. Two apps also run on different port. Also I'm doing SSR on the frontend.
Next.js already includes a server like express. API Routes allow you to build a backend deployed along with the rest of the next application.
API Routes live in the /pages/api folder.
Think longterm. If in the future, it'll need to be scaled to accommodate traffic or have must separate domains then separating the backend from the frontend is the best way to go. This way each team can focus on their part without messing up the organization of the entire project. Also you have a clean interface for your clients (frontend, CLI and SDK). If not then having the backend in NextJS should be fine.
I am aware that my topic is already has many answers, but I can not find what I need and want to listen to cutting edge trend.
I am building react application with create-react-app and nestjs as backend server. After deployment I found out that there is some trouble with SEO on my website and I thought my app deploying structure might be wrong.
Here is my structure.
S3 for react app hosting.
Cloudfront
Nestjs server on EC2
RDS for database
Route53
So my react app website url is https://myapp.com, server url is https://server.myapp.com. I call server apis on client by using axios with server url like https://server.myapp.com/v1/users.
I found out many people deploy there both client and server in one EC2 instance using tools like NGINX or APACHE. The reason I was not adopting these were the benefit of using cloud services was I do not have to concern about these. But after deploying applications, it seems deploying on same instance is more better is many ways.
Can I listen to some ways of structuring web app deployment with server? And is my structure is the reason of poor SEO?
It's upon to you how you want to deeply and host your frontend and backend whether on the same instance or different instances it's according to your apps traffic and whole other factors.
Now we come upon the SEO part. In your case, the first SEO factor will be the content that you are serving on the internet and another factor will be the performance of your website. The content part totally depends upon you that how you are designing it or writing the content. But there are some strategies I can share on increasing your performance so that this factor doesn't create any chaos for you.
Since your content generation is dynamic and it will generate when the user requests a particular resource from your server. So caching can help you here to optimize the initial server response time. So you can cache your content by using Nginx, varnish, or use a service like Cloudflare.
I want set up a fullstack app with strapi and react. All tutorials i've seen say to deploy frontend on netlify and backend to something like heroku. Is there a posibility to deploy full app at one hosting?
I mean user entering website will get react app and backend will be running at onother port on the same hosing
You can host both the front end(react) and backend(strapi) on heroku.
they can be hosted as two different individual apps running on different dynos and they can even be hosted as a single app together.
see this answer:
How to deploy Strapi backend and ReactJS frontend to a single Heroku app
You definitely can deploy both on the same server, the question is whether you should do that.
What if your system has another client, like mobile app? Or what if you have more than one API server, and several databases (e.g. mongo and redis)? You don't want to put all of them on a single server, do you? By deploying them separately you can benefit from horizontal scaling, i.e. you upgrade your hosting plan on particular server whenever it needs more resources, without affecting another nodes. Divide and rule!
If you still want to deploy React and back-end on the same server, the better place for that would be something like DigitalOcean. On single droplet you can place as many servers as you want and configure them to launch on different ports.
I'm trying to build an offline first web application using couchdb and pouchdb as the backend/frontend databases, AngularJS as the frontend framework and expressjs/nodejs as the backend server. The problem is that what I'm used to is the backend-MVC mindset of building web apps, and not to SPAs, offline-first design, or having only json apis on the application server.
The problem I see with the design I'm considering is that I don't see any role of the nodejs server except serving static files. The frontend would get data from the pouchdb database which would sync with the couchdb database backend. I need an offline-first application capable of working locally when there's no connectivity and syncing when connectivity is available, so this is important.
But where do I implement the important bits of application logic that I need in the backend, like form input validation or user access control? I found some ways to embed logic in couchdb databases (like using filters as shown here) but somehow writing application logic in the database doesn't feel right.
What part of the big picture am I missing here?
I'm trying to solve some of my question regarding the architecture of a system consisting of the following:
AngularJS web application frontend
MapServer generating & serving map images through WMS
Lumen REST API backend containing all the business logic
PostgreSQL database with PostGIS to store spatial data
Which is the proper way to dockerize that kind of stack?
Currently i'm thinking of the following containers to be created:
Web Server containing:
Apache web server
AngularJS frontend application
Map Server containing:
Apache web server with CGI support
MapServer CGI application
MapCache/TileCache
Application Server container:
Apache web server
Lumen API backend
Database containing:
PostgreSQL relational database
PostGIS add-on
The list of components of each container has not been yet finalized, so some of them may not fit exactly where they have been placed. For example, should Apache be on a separate container?
Let's think about docker philosophy, Microservices.
Microservices is an approach to application development in which a
large application is built as a suite of modular services. Each module
supports a specific business goal and uses a simple, well-defined
interface to communicate with other modules.
Meaning we need to split our system into microservices, and put each microservice into a container. This will help you significantly when you try to upgrade your application.
In your case, I would separate apache from angular js container.