I have got a small radio service running on Node.js. Front end is written with React and packed with Webpack . I use Docker for my #DeploymentWorkflow along with Docker Swarm and GitLab CI on a single Google Compute Engine instance, which is also a runner itself. Pretty unscalable decision but it works great for tiny projects. The project is available on https://fridgefm.com
Our CLI was originally written Node.js with npm , 2 years ago. We have now migrated to Go !
It was something we quickly hacked together at the early beginnings of Uilicious when our focus was to move fast and iterate the product quickly. We wanted to roll out the CLI ASAP, so that users with a CI/CD can hook up their tests to their front-end deployment pipeline.
However after 2 years, with NPM dependency hell pains - We decided to migrate our CLI toolchain to Go for
Happy with how it is : article covers the decision in much deeper details
https://dev.to/uilicious/why-we-migrated-our-cli-from-nodejs-to-golang-1ol8
We undertook the task of building a manufacturing ERP for small branded manufacturers. We needed to build a lot, fast with a small team, and have clear focus on product delivery. We chose JavaScript / Node.js ( React + LoopBack full stack) , Heroku and Heroku Postgres (also Heroku Redis ) . This decision has guided us to picking other key technologies. It has granted us high pace of product delivery and service availability while operating with a small team.
I'm building most projects using: Server: either Fastify (all projects going forward) or ExpressJS on Node.js (existing, previously) on the server side, and Client app: either Vuetify (currently) or Quasar Framework (going forward) on Vue.js with vuex on Electron for the UI to deliver both web-based and desktop applications for multiple platforms.
The direct support for Android and iOS in Quasar Framework will make it my go-to client UI platform for any new client-side or web work. On the server, I'll probably use Fastly for all my server work, unless I get into Go more in the future.
Update: The mobile support in Quasar is not a sufficiently compelling reason to move me from Vuetify. I have decided to stick with Vuetify for a UI for Vue, as it is richer in components and enables a really great-looking professional result. For mobile platforms, I will just use Cordova to wrap the Vue+Vuetify app for mobile, and Electron to wrap it for desktop platforms.
Update: The mobile support in Quasar is not a sufficiently compelling reason to move me from Vuetify. I have decided to stick with Vuetify for a UI for Vue, as it is richer in components and enables a really great-looking professional result. For mobile platforms, I will just use Cordova to wrap the Vue+Vuetify app for mobile, and Electron to wrap it for desktop platforms.
Vue.js vuex Vue Router Quasar Framework Electron Node.js npm Yarn Git GitHub Netlify My tech stack that helps me develop quickly and efficiently. Wouldn't want it any other way.
We are in the process of building a modern content platform to deliver our content through various channels. We decided to go with Microservices architecture as we wanted scale. Microservice architecture style is an approach to developing an application as a suite of small independently deployable services built around specific business capabilities. You can gain modularity, extensive parallelism and cost-effective scaling by deploying services across many distributed servers. Microservices modularity facilitates independent updates/deployments, and helps to avoid single point of failure, which can help prevent large-scale outages. We also decided to use Event Driven Architecture pattern which is a popular distributed asynchronous architecture pattern used to produce highly scalable applications. The event-driven architecture is made up of highly decoupled, single-purpose event processing components that asynchronously receive and process events.
To build our #Backend capabilities we decided to use the following: 1. #Microservices - Java with Spring Boot , Node.js with ExpressJS and Python with Flask 2. #Eventsourcingframework - Amazon Kinesis , Amazon Kinesis Firehose , Amazon SNS , Amazon SQS, AWS Lambda 3. #Data - Amazon RDS , Amazon DynamoDB , Amazon S3 , MongoDB Atlas
To build #Webapps we decided to use Angular 2 with RxJS
#Devops - GitHub , Travis CI , Terraform , Docker , Serverless
At IT Minds we create customized internal or #B2B web and mobile apps. I have a go to stack that I pitch to our customers consisting of 3 core areas. 1) A data core #backend . 2) A micro #serverless #backend. 3) A user client #frontend.
For the Data Core I create a backend using TypeScript Node.js and with TypeORM connecting to a PostgreSQL Exposing an action based api with Apollo GraphQL
For the micro serverless backend, which purpose is verification for authentication, autorization, logins and the likes. It is created with Next.js api pages. Using MongoDB to store essential information, caching etc.
Finally the frontend is built with React using Next.js , TypeScript and @Apollo. We create the frontend as a PWA and have a AMP landing page by default.
From a StackShare Community member: “I’m a freelance web developer (I mostly use Node.js) and for future projects I’m debating between npm or Yarn as my default package manager. I’m a minimalist so I hate installing software if I don’t need to- in this case that would be Yarn. For those who made the switch from npm to Yarn, what benefits have you noticed? For those who stuck with npm, are you happy you with it?"
We use Yarn because it allows us to more simply manage our node_modules. It also simplifies commands and increases speed when installing modules. Our teams module download time was cut in half after switching from NPM to Yarn. We now require all employees to use Yarn (to prevent errors with package-lock.json and yarn.lock).
We recently made the switch to Yarn mostly because of workspaces, speed, and the features in the Yarn v2 release. It has been great.
I use npm since new version is pretty fast as well (Yarn may be still faster a bit but the difference isn't huge). No need for other dependency and mainly Yarn sometimes do not work. Sometimes when I want to install project dependencies I got error using Yarn but with npm everything is installed correctly.
I've been using Django for quite a long time and in my opinion I would never switch from it. My company is currently using Django with REST framework and a part in GraphQL using Graphene. On the frontend we use Next.js and so far everything has been running quite good. I've found limitations but manage to solve it.
As someone mentioned before, if you are comfortable with Django, don't switch. There's no need since with django you can basically achieve anything. Of course this will depend on the project you want to build, but the scalability and flexibility django can offer it's just out of this world. (Don't want to sound like a fan boy haha but it really is).
It's been ages since I last used Django, but if you're proficient with it, I'd suggest you stick to it in order to deliver results quickly and on time. On the other hand, if time is not an issue, I'd recommend you start learning Node.js with express.js or loopback.js.
I haven't found something similar to Django in terms of a built in full fledge admin and CMS but, in my opinion, since you are using JavaScript (Angular.js) on the frontend, I think you could benefit from using JavaScript in the backend.
Bottom line: Start learning Node, keep using Django till you get proficient at Node, then move to Node ;)
I haven't found anything close to the Django admin in Node.
Keep in mind that comparing Node.js with Django is not quite right. It's like comparing Python with express.js
I haven't used Django but have a lot of experience with python and other similar frameworks. I have been using Node.js most recently and extensively. Node.js is honestly nice. I love python, but I always hated Javascript, and the whole thing feels "sloppy." But it seems to be very fast, and I really do love the asynchronous support, and have to concede that it has served us well. It's a bit tricky to get accustomed to at first, and can really get you in knots, but when you get comfortable, it's fast. I also like that it's so widely supported so both in terms of scaling and a wide developer base. In the end you can make anything work in any framework. I've used many. Pick one and stick to it. For each framework you can find a great company that uses it.
