Yes, because it's the easiest codebase to manage and maintain. Everything new is in NodeJS.
Build process is all in NodeJS as well, creating build processes in other tecnologies used to be a headache.
Only if it's something very specific and focused I would use the API's language which is "Java" ou ".NET".
The only problem about Typescript is locking-in your script into a framework, I don't like lockins, I would recommend leaving your code in NodeJS only.
React is a nice piece of technology, but you need to understand it very well. Otherwise you might loose performance instead of obtaining performance.
Lambda (Serverless API) - I've used a lot and it's awesome.
Ok, but if it's react it's a web or mobile web project. Then you'll still need to render DOM in the browser and it doesn't matter if you have more or less processing in the backend, you'll always need to care about your frontend.
If you think TypeScript has a lot more benefits then fine, you may go forward with it. I'm just conservative in this perspective. I understand you may transpile (build process), that's fine, I don't like working in Visual Studio, I prefer Atom and having my code without transpiling, not sure how it will work out with your build process when creating a zip to upload to Lambda, but best of luck.
I disagree that performance always matters. I don't pre-optimize. If I can create better UX by focusing on performance, I will. Currently my front ends are so light that a human can't tell the difference.
I don't use Visual Studio either. VS Code is based on Atom, and it has great TypeScript support. I use WebStorm, which is a better IDE overall right now.
I understand people not wanting to transpile, and it does suck that JS forces so many of us to do it.
@smt88 that's fine, but when I talk about performance I'm not talking about what a human eye can see, but rather what Google wants in terms of performance.
Java back end, HTTP/2, everything tuned for small transfer size and high speed, no CDN, no extra DNS lookups, as little JavaScript as possible, but maybe d3.js or something else which adds a lot of value.
There is not one tool I would use/recommend before knowing the actual requirements.
In one of our latest projects we decided on following stack:
Backend/API: PHP, Symfony3, Mysql
We choose this because the following reasons:
The team is already familiar with symfony/php
We had to integrate with existing stack/business logic in php ( or port parts of it )
Frontend: Angular.js
We needed a single page app that we could easily port parts of to a mobile app later on
We wanted to decouple our frontend from the backend by doing only api calls so we avoid having backend code responsible for generating html/etc
Real-time component: Node.js, Redis
We needed a component that processes events as they come in, and a lot of them. We decided against PHP so we could lower our memory footprint and also because it is a bit more convenient to deal with state.
This component checks each incoming data packet with a set of rules and reports on violations.
This component gets it's configuration from the backend api and reports back to the api whenever a violation occurs which needs to be logged.
Right now, if tasked with building another service of the same type as the one I am currently creating (kind of a CRM integrated with various 3-rd party payments and messaging) I'd use the most recent version of my current stack.
My current stack is JavaEE on TomEE.
I'd probably happily sacrifice verified stack compliance for the latest TomEE 7 milestone build as I understand the verification issue is just Oracle being Oracle again, throwing a wrench in the gears just because 'why not'? Or rather to see if they can somehow extort some money from an open source project. </rant>
If it's just you, and a first outing, then a minimal set of whatever you're most familiar with. For me that would be nginx -> wsgi -> flask/bottle or similar -> postgresql, because python. Similar if you're more comfortable with ruby, js, whatever. Build out from there if it becomes worthwhile.
If you're a group, whatever allows the group to make best progress.
This long weekend (US) I started a project hosted in Linode running Debian. I am writing code in Go, HTML, JS, CSS using jEdit on Gentoo desktop (4 monitors). The backend stuffs are Redis and Solr. I used Bower to add web components. I still use Makefile rather than grunt or other newish things
That depends so heavily on your requirements that every general answer is incomplete.
There are lots of different kinds of web apps with very different requirements.
There are tools for solving certain problems in frontends and other tools for certain problems in backends. There are tools for small projects and others for large scale products...
As long as there is no specific problem you can't say what's the right tool.
I would use Rails. Rails has everything I need to build a web app and API back end should I require a native mobile app. As a ruby guy I can't really comment on the frontend, but my go to JS framework that lets me build shit quickly is knockoutjs.
And those tools today are often a mix of my own code and some SaaS.
Depending on how much data management there is, I will ususally start with Django, specifically Django Cookie Cutter [1].
This bootstraps a lot of the basics for me like user auth, testing, front-end assets, etc.
For error console, I will use Sentry[2]. There are self-hosted and paid versions.
If I want some real-time type functionality, I will use Pubnub [3]
I am lazy and will always play to my strengths. That happens to be Python, Postgres, and constantly hunting tools that make me an even lazier developer.
Situation dictates:
Any kind of business website/ blog/ landing page is probably going to be Wordpress. Not because I really like Wordpress, but because it's fast. These are "good enough" pages.
For anything else, I'm likely to choose Flask if I can. I think Flask strikes the right balance for me between having all of the features I want without bogging me down.
For the front end, I normally just stick with html/css and Bootstrap or another css library.
29 comments
[ 11.4 ms ] story [ 73.9 ms ] threadHosting: Lambda via Serverless for API, S3 for HTML/assets
API: Node/JS via TypeScript, Postgres RDS, GraphQL
Front end: React
React is a nice piece of technology, but you need to understand it very well. Otherwise you might loose performance instead of obtaining performance.
Lambda (Serverless API) - I've used a lot and it's awesome.
As for TypeScript, I'm not sure I understand what you mean. How is it locking me in any more than React or something?
If TypeScript dies as a project, I would still be able to transpile my latest code and then continue writing pure JS...
Also, whatever risk there is of that happening, the productivity boost of TypeScript far outweighs it for me.
If you think TypeScript has a lot more benefits then fine, you may go forward with it. I'm just conservative in this perspective. I understand you may transpile (build process), that's fine, I don't like working in Visual Studio, I prefer Atom and having my code without transpiling, not sure how it will work out with your build process when creating a zip to upload to Lambda, but best of luck.
I don't use Visual Studio either. VS Code is based on Atom, and it has great TypeScript support. I use WebStorm, which is a better IDE overall right now.
I understand people not wanting to transpile, and it does suck that JS forces so many of us to do it.
Best Regards,
In one of our latest projects we decided on following stack:
Backend/API: PHP, Symfony3, Mysql
We choose this because the following reasons:
The team is already familiar with symfony/php We had to integrate with existing stack/business logic in php ( or port parts of it )
Frontend: Angular.js
We needed a single page app that we could easily port parts of to a mobile app later on We wanted to decouple our frontend from the backend by doing only api calls so we avoid having backend code responsible for generating html/etc
Real-time component: Node.js, Redis
We needed a component that processes events as they come in, and a lot of them. We decided against PHP so we could lower our memory footprint and also because it is a bit more convenient to deal with state.
This component checks each incoming data packet with a set of rules and reports on violations.
This component gets it's configuration from the backend api and reports back to the api whenever a violation occurs which needs to be logged.
Backend: PHP (Yii2), Mysql, Redis
Frontend: React (if I can't get away with just JQuery), Bootstrap 3
Realtime components: Node.js, Socket.io
My current stack is JavaEE on TomEE.
I'd probably happily sacrifice verified stack compliance for the latest TomEE 7 milestone build as I understand the verification issue is just Oracle being Oracle again, throwing a wrench in the gears just because 'why not'? Or rather to see if they can somehow extort some money from an open source project. </rant>
Haven't used but wish-list to try next: Docker, GraphQL, and probably try hosting it on google cloud platform
If the use-case fits, even wanna try a Firebase-backend only app as well
Database: Postgres and possibly Redis
Frontend: Not much of a front-end person so I avoid all the complicated stuff and stick with Bootstrap. I also tend to prefer coffescript
If it's just you, and a first outing, then a minimal set of whatever you're most familiar with. For me that would be nginx -> wsgi -> flask/bottle or similar -> postgresql, because python. Similar if you're more comfortable with ruby, js, whatever. Build out from there if it becomes worthwhile.
If you're a group, whatever allows the group to make best progress.
Haskell yesod and elm for fun
Personally, I would go for Flask just because it's so easy to build up momentum due to the minimal setup required.
I would use Rails. Rails has everything I need to build a web app and API back end should I require a native mobile app. As a ruby guy I can't really comment on the frontend, but my go to JS framework that lets me build shit quickly is knockoutjs.
And those tools today are often a mix of my own code and some SaaS.
Depending on how much data management there is, I will ususally start with Django, specifically Django Cookie Cutter [1].
This bootstraps a lot of the basics for me like user auth, testing, front-end assets, etc.
For error console, I will use Sentry[2]. There are self-hosted and paid versions.
If I want some real-time type functionality, I will use Pubnub [3]
I am lazy and will always play to my strengths. That happens to be Python, Postgres, and constantly hunting tools that make me an even lazier developer.
[1] - https://github.com/pydanny/cookiecutter-django
[2] - https://getsentry.com
[3] - https://pubnub.com
In the future I want to use the following setup: ASP.NET Core with Angular 2 and Typescript. And then host it on Azure. Sounds like a golden combi.