Alternatives to NestJS

Recently I have been working on an open source stack to help people consolidate their personal health data in a single database so that AI and analytics apps can be run against it to find personalized treatments. We chose to go with a #containerized approach leveraging Docker #containers with a local development environment setup with Docker Compose and nginx for container routing. For the production environment we chose to pull code from GitHub and build/push images using Jenkins and using Kubernetes to deploy to Amazon EC2.

We also implemented a dashboard app to handle user authentication/authorization, as well as a custom SSO server that runs on Heroku which allows experts to easily visit more than one instance without having to login repeatedly. The #Backend was implemented using my favorite #Stack which consists of FeathersJS on top of Node.js and ExpressJS with PostgreSQL as the main database. The #Frontend was implemented using React, Redux.js, Semantic UI React and the FeathersJS client. Though testing was light on this project, we chose to use AVA as well as ESLint to keep the codebase clean and consistent.

Quasar Framework Node.js ExpressJS FeathersJS MongoDB Netlify I just love this stack, it's VERY fast to start working on your own stuff instead of internal details.

We are using Node.js and ExpressJS to build a REST services that is middleware of a legacy system. MongoDB as database. Vue.js helps us to make rapid UI to test use cases. Frontend is build for mobile with Ionic . We like using JavaScript and ES6 .

I think next step could be to use Koa but I am not sure.

Will base most server-side APIs on Fastify . Smaller, faster, easier. Faster than Koa; and twice as fast as ExpressJS.

I use LoopBack because it is: * It is truly and Unbelievably Extensible * it is default integrated with OpenAPI (Swagger) Spec Driven REST API * I write lesser codes, because most of the user stories have been covered using the code generation * It's documentation is more compact and well detailed than ExpressJS * It is very easy to learn, hence you can build a basic Rest API App in minutes * It has built in NPM packages required to build my Rest API which saves me time on installation and configuration * The Datasource/Service/Controller concept is just Brilliant (that's mostly all you need to get your app speaking with an External API services) * The support for SOAP and Rest API services is amazing!

React LoopBack Node.js ExpressJS Elasticsearch Kibana Logstash Sequelize Mocha Chai Visual Studio Code are the combo of technologies being used by me to build BestPrice Extension with all its micro-services & Web-based fragments

What is the best way to increase your income as a freelancer in 2019? What frameworks should be the best to learn? React Node.js Docker Kubernetes Sequelize Mongoose MongoDB ExpressJS hapi Based on trends I've picked up a JS full stack. If you need to work under startups you may replace React with Vue.js . If you want to work in outsourcing Angular 2+ may be better.

What is your opinion?

Winds 2.0 is an open source Podcast/RSS reader developed by Stream with a core goal to enable a wide range of developers to contribute.

We chose JavaScript because nearly every developer knows or can, at the very least, read JavaScript. With ES6 and Node.js v10.x.x, it’s become a very capable language. Async/Await is powerful and easy to use (Async/Await vs Promises). Babel allows us to experiment with next-generation JavaScript (features that are not in the official JavaScript spec yet). Yarn allows us to consistently install packages quickly (and is filled with tons of new tricks)

We’re using JavaScript for everything – both front and backend. Most of our team is experienced with Go and Python, so Node was not an obvious choice for this app.

Sure... there will be haters who refuse to acknowledge that there is anything remotely positive about JavaScript (there are even rants on Hacker News about Node.js); however, without writing completely in JavaScript, we would not have seen the results we did.

#FrameworksFullStack #Languages

When I joined NYT there was already broad dissatisfaction with the LAMP (Linux Apache HTTP Server MySQL PHP) Stack and the front end framework, in particular. So, I wasn't passing judgment on it. I mean, LAMP's fine, you can do good work in LAMP. It's a little dated at this point, but it's not ... I didn't want to rip it out for its own sake, but everyone else was like, "We don't like this, it's really inflexible." And I remember from being outside the company when that was called MIT FIVE when it had launched. And been observing it from the outside, and I was like, you guys took so long to do that and you did it so carefully, and yet you're not happy with your decisions. Why is that? That was more the impetus. If we're going to do this again, how are we going to do it in a way that we're gonna get a better result?

So we're moving quickly away from LAMP, I would say. So, right now, the new front end is React based and using Apollo. And we've been in a long, protracted, gradual rollout of the core experiences.

React is now talking to GraphQL as a primary API. There's a Node.js back end, to the front end, which is mainly for server-side rendering, as well.

Behind there, the main repository for the GraphQL server is a big table repository, that we call Bodega because it's a convenience store. And that reads off of a Kafka pipeline.