For a project i have to create website showing data from a database with data that changes frequently (sensor data: temperaturen, humidity,...). This by making an API to get the data. I created a REST api in Node.js to do this.
So Database -> API -> WEBSITE
What would be the best way to create the Dynamic website and what is the best practice to get the API to the outside using AWS? And in this solution, is it usefull to use NGINX in any way?
Other suggestions and literature about the subject are also welcome.
To create the dynamic site i would say use angular JS/Angular2 which provides you the capability of two way data binding and make life easy to implement the website in quick period of time. For REST API you have used NODEJS which you can host to AWS and provide a reverse proxy viz; NGINX. the use of reverse proxy is useful in case of high traffic sites;which also protects the NodeJS server from direct exposure to Internet traffic and allows you a great deal of flexibility in using multiple application servers, in load balancing across the servers, and in caching content. So if you think your app is having heavy traffic you can use NGINX
So technology stack for you can be something like MEAN (MongoDB -if you also need to choose db; ExpressJs,NODEJS and ANGULAR) which hosted on AWS EC2 server.
Apart from this in case you dont want to maintain server you can also think of serverless architecture on aws (with lamda). Hope my answer will give you good pointers further.
Related
We have a web app (CRM type) working on Linux (Debian) with Apache, MariaDb and PHP for the backend, and AngularJS (1.x) for the frontend.
Thinking about a redesign, I need advices on a solution I have in mind, but I'm not sure it would be relevant...
A new website (e-commerce) will come along the CRM and use directly or not (API) the same database.
So my first take would be to put the MariaDb on a dedicated VM. It uses much ressource right now, so much more with another app using it.
Then the CRM and website could connect directly in remote (too risky?) or call an API. I guess the second solution would be better and means I could put my backend PHP part (already working as an API for AngularJS) along with the database, on that new VM.
I guess Debian + Nginx would be a good choice to go with them.
I prefere PHP to handle databases 'cause I'm used to it.
On the other hand I would still have AngularJS alone, a deprecated JS framework.
One thing that was hard to work with, about AngularJS/PHP, was that sometimes I needed to format data for Angular from PHP, and vice versa. It wasn't very clear where to put that formating, 'cause the backend was more about the database and not the frontend, and the frontend more about layout than PHP ORM ans design.
Furthermore, we'd like to keep the CRM as a SPA (Single Page Application).
My take on that would be to go on a MEAN stack, without de M (MongoDB), starting from scratch, just keeping Debian and installing NodeJS, ExpressJS and Angular or another JS framework (Vue, React...).
A hole JS stack to have the same language and gain speed and performance with many little transactions with the server (assets, calls and promises to retrieve data from database). Also to learn more on JS and NodeJS particularly.
NodeJS to create the environnement and a web server, in place of Apache.
Angular (or another) to put data into HTML, and have the less treatments possible.
ExpressJS to be that intermediate part I was talking to, the place where formating can be performed: retrieving data from the views, formating them, sending them to the API, handling the response, formating it if necessary and returning it to the view.
It means I would go from one VM with:
AngularJS (frontend) -> PHP framework (backend) -> Database
To two VM with:
Angular (app frontend) -> Express (app backend) -> PHP API (database backend) -> Database.
What do you think of my use-case and the solution?
There are several benefits to splitting up your services, but almost equally many different solutions, so you need to ask yourself what your goal is. Performance? High availability/failover? You might need a lot of VMs, geo-redundancy, load-balanced VIPs, etc.
You can also look into making containerized services with Docker.
You talk about moving the database onto a separate VM, but that it might be risky. Why? If they are both on an isolated network, it should not be an issue.
If you're looking for stack advice, since you're talking about a full remake, I would recommend something both stable and modern like Laravel + VueJS for the web/API part. You're already comfortable with PHP, and a setup with Nginx will probably be much faster. But of course, there are almost infinite combinations to choose from these days.
As for the "direct or not" DB access: Having a versioned API is always a benefit.
Serving the SPA frontend will require very few resources, so your bottleneck will be between the API backend and DB. You can make it scalable by putting the API behind a VIP and load balance with something like HAProxy/Nginx.
I was making a thinking exercise about how could I deploy a chat service like WhatsApp or Slack (just wondering), so people could really use it. You need two main parts, the client software (e.g. the app running on the smartphones), and the server software. So how would you develop the server-side code and make it work?
The first idea that came to me was the classic hosting service, but it cannot be the simple "web hosting service", probably because something like this should be programmed at a lower level and not working with HTTP requests and responses. Maybe using specific server-side technology like Node.js (any other suggestion?) to manage different type of requests at lower level, let's say at the layer where TCP lives, would be a better solution.
So I heard about the Amazon Web Services (AWS), which is not classic hosting, it's a cloud computing service. The problem is that I don't know exactly how this works. Could I deploy a server-side application that works at that low level of networking and also makes requests to databases? Would it be difficult to offer this kinf of service using AWS?.
I would like to hear all your opinions about any aspect of this. Would you use other kinf of technology on the server? What do you think about AWS, and if you would think it's a good option, where can I get some info to learn how to use it?
Server Side Code
You can create a chat service backend using NodeJS + express(or Hapi) to cater input Http Requests.
For Hosting: Cloud servers are pretty available these days and allow you to scale if your app grows with time.
Database:
if you already have your DB available (cool) just use ORMs ( like (Sequelize) which provides easy interaction of Nodejs service with your DB. (I have used MySQL + Sql Server + Oracle)
If not, you can create a new DB (MySql- free on your hosting server (cloud?)
I used Microsoft Azure to host a Nodejs(+ Hapi.js) Backend Service ,to be consumed by my mobile application, over the internet.
Azure gives you $200 free credit which is sufficient for you to try and make your hands dirty with them. There are numerous tutorials available for MS-Azure Api App hosting which will guide you to a successful deployment.
I have not yet explored AWS as of now, but i trust that they will be similar in their learning curves.
Background
Our backend is currently written in Grails. We would like to change the backend to NodeJs. We would like to execute the change in small iterations. We deploy everything on AWS.
Question
How to change the technology from Grails to NodeJs iteratively?
My opinion
Although we don't use Microservice Architecture (and none of us has any experience with it) I personally would:
build a NodeJs server before our Grails server (something like a Gateway API maybe?)
at first the NodeJs would just pass requests/responses to/from Grails
then we would move other functionality from Grails (request logging, validations, ...) until we moved everything needed. (Maybe we keep something on Grails but most of the logic should end up on NodeJs.)
We have done a successful migration from Ruby & Rails to API Gateway & Lambda based Microservices written in NodeJS. The same architecture you can use if you prefer NodeJS server (Without Microservices) or using Docker Containers Cluster with ECS.
Setup CloudFront as a Proxy which will be getting all the HTTP traffic to your application domain (You can map the DNS to CloudFront CName)
In CloudFront you can add the current Grails Application as the default origin and behavior which makes your application works as it is same as today.
Then you can setup your Microservices Architecture with API Gateway and Lambda or NodeJS Web Server or Docker Container Cluster with ECS seperately. (Note that if you use a Relational Database like MySQL, it also requires to do proper placement of new server code in Lambda, WebServer or Containers so that it can access the Database)
Afterwards, you can write the new feature logic and override one http subpath at a time from CloudFront pointing to the new application.
Following diagram shows the architecture in high-level.
Note: In the diagram, it uses DynamoDB for new Microservices and in the migration phase, you can also connect to the current Database with proper VPC, Subnet and Server placement.
In Addition you gets the benefits from CloudFront CDN in caching static assets to improve application performance and also you will be able to terminate the SSL handhshake in CloudFront with free SSL Certificates issued by Amazon.
Your approach is definitely possible. But I'd take another one and try using microservices. Then you will move parts of your code one by one to little cute microservices and eventually have microservice architecture. I like this approach because it allows very fast switching... Of everything. You can build your microservices with Java, Node, Go - everything you want. And if you suddenly discover that node.js is not up to your expectations (for example, if you have hardcore math modules) - just throw this microservice out and quickly impliment it in any other language and framework. The most important part is defining communication architecture. REST API is already a thing of the past and you will possibly want to use some message broker like RabbitMQ.
I have written a real-time multiplayer game and currently writing its server in NodeJS. I want my game to have login, level up etc, so I need to have a database. This is the first time I am deploying something and I am mostly self taught, so please correct me if I am mixing things up. Since this is my first trial, I do not want to make much commitment right away so I am looking for free options only. And since this should be a real-time game, I need a relatively fast server response. That is why I am looking for the easiest database and server provider that would do and I am aware that with those restrictions I have limited choices and functionality.
As far as I have read online, Heroku seems to be my simplest option for a server (that is why I started writing in NodeJS). However it seems like there is no free database service since all options on https://devcenter.heroku.com/articles/heroku-postgres-plans has monthly fee. I did not want to use Google App Engine since I am new (it certainly is not mentioned as beginner friendly).
So I have found AWS following Free Cloud Database Service for home development post, it seems like I could use Amazon Web Services as a server and database. However most posts I have encountered suggests Google App Engine or Heroku with little mention of AWS. Is this because I am mixing concepts up, or does AWS have drawbacks that I am not aware of? Do you think it is a good idea to use AWS for both as server and database, is it possible to use Heroku as server while using AWS as database or do you have any other suggestion?
Note: Sorry for the question bombardment but those are all related and I am sort of lost in this topic so I had to ask...
Use AWS EC2 for the server and RDS for the database. The reason why people use heroku is that it deploys to a custom url very quickly (it's easy to set up). Setting up AWS requires some knowledge of how servers work, but it's not that complicated (and it's free for small apps). Best of luck!
Am I correct in the assumption that without access to the MongoDB server, there is not much point developing with Meteor?
Meteor is a great framework for building, packaging and deploy apps and sites. From a development POV, the templating and responsive DB work make prototyping so much easier than most MVC's.
I understand that underneath the hood, websockets and DDP provide the realtime sync'ing magic which means that you need access to the MongoDB server, something you don't have with PaaS solutions like GoogleAppEngine, Parse or Kinvey.
So, for the backend developer, they don't derive much benefit from Meteor since they need to maintain the server stack and scalability issues.
Is there a path to create and deploy products with Meteor without having to build and maintain the backend infrastructure? Heroku is still pretty close to the bone when it comes to managing infrastructure.
Wondering if there's a way to have CRUD operations through a REST driver that maps out to whatever PaaS you want and have the PaaS post log changes to a server that strictly handles websocket connections. Basically, pass the CRUD operation to a PaaS and maintain your own websocket server/s.
MeteorPedia has a page on deploying to PaaS: http://www.meteorpedia.com/read/Category:PaaS_providers
Recently, Google AppEngine has added support for custom VMs.
You can also use MongoHQ or similar for the database.