Alternatives to TypeORM

Hey! I am actually in internship and have an app to create for my structure. It will be an intern app which will allow crud dashboard actions with some data provided by the use of an API of one of the structure partner and make a correspondence to data contained in a private database. Since it's an intern app, I thought about Electron for a desktop app because I did a lot of web with Laravel and the structure goes more for the desktop app. But it will be my first occasion working with this tech.

Is Electron a good choice? Wich ORM should be more complete and adapted to this between Sequelize and TypeORM? (Database will be MySQL) Some charts will be displayed in the app. Is there a library (preferably without jQuery) that suits this stack?

Thank you !

Node.js is a great option for real-time applications, especially in conjunction with Socket.IO.

In terms of databases, I'd go with PostgreSQL. MongoDB has its benefits (schema-less, sharding, map-reduce), but for most CRUD-based apps, it makes sense to store the bulk of your data in a relational database (of which PostgreSQL is the best IMO). You can throw in MongoDB if you have a specific need for it. There's certainly no need to use both MySQL and PostgreSQL.

As for GraphQL, it can be nice to work with since you don't need to predefine specific data endpoints on your backend, instead shifting the power to your frontend in requesting the data it needs. It's also useful for public APIs, when you don't know what data users want (see Github's API). It can be useful at the early stage when you're prototyping and want to be able to fetch data quickly, but certainly isn't necessary.

At BaseDash we use Node.js, ExpressJS, Socket.IO, PostgreSQL, and Sequelize to fit our use case of database management and real-time operations.

Repost

Overview: To put it simply, we plan to use the MERN stack to build our web application. MongoDB will be used as our primary database. We will use ExpressJS alongside Node.js to set up our API endpoints. Additionally, we plan to use React to build our SPA on the client side and use Redis on the server side as our primary caching solution. Initially, while working on the project, we plan to deploy our server and client both on Heroku . However, Heroku is very limited and we will need the benefits of an Infrastructure as a Service so we will use Amazon EC2 to later deploy our final version of the application.

Serverside: nodemon will allow us to automatically restart a running instance of our node app when files changes take place. We decided to use MongoDB because it is a non relational database which uses the Document Object Model. This allows a lot of flexibility as compared to a RDMS like SQL which requires a very structural model of data that does not change too much. Another strength of MongoDB is its ease in scalability. We will use Mongoose along side MongoDB to model our application data. Additionally, we will host our MongoDB cluster remotely on MongoDB Atlas. Bcrypt will be used to encrypt user passwords that will be stored in the DB. This is to avoid the risks of storing plain text passwords. Moreover, we will use Cloudinary to store images uploaded by the user. We will also use the Twilio SendGrid API to enable automated emails sent by our application. To protect private API endpoints, we will use JSON Web Token and Passport. Also, PayPal will be used as a payment gateway to accept payments from users.

Client Side: As mentioned earlier, we will use React to build our SPA. React uses a virtual DOM which is very efficient in rendering a page. Also React will allow us to reuse components. Furthermore, it is very popular and there is a large community that uses React so it can be helpful if we run into issues. We also plan to make a cross platform mobile application later and using React will allow us to reuse a lot of our code with React Native. Redux will be used to manage state. Redux works great with React and will help us manage a global state in the app and avoid the complications of each component having its own state. Additionally, we will use Bootstrap components and custom CSS to style our app.

Other: Git will be used for version control. During the later stages of our project, we will use Google Analytics to collect useful data regarding user interactions. Moreover, Slack will be our primary communication tool. Also, we will use Visual Studio Code as our primary code editor because it is very light weight and has a wide variety of extensions that will boost productivity. Postman will be used to interact with and debug our API endpoints.

REST API for SaaS application

I'm currently developing an Azure Functions REST API with TypeScript, tsoa, Mongoose, and Typegoose that contains simple CRUD activities. It does the job and has type-safety as well as the ability to generate OpenAPI specs for me.

However, as the app scales up, there are more duplicated codes (for similar operations - like CRUD in each different model). It's also becoming more complex because I need to implement a multi-tenancy SaaS for both the API and the database.

So I chose to implement a repository pattern, and I have a "feeling" that .NET and C# will make development easier because, unlike TypeScript, it includes native support for Dependency Injection and great things like LINQ.

It wouldn't take much effort to migrate because I can easily translate interfaces and basic CRUD operations to C#. So, I'm looking for advice on whether it's worth converting from TypeScript to.NET.

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.

We have an existing (Apis only) Rails backend, that by default follows the MVC pattern, (at peaks of 700 requests a second). I am tasked with making the same (read-heavy) application in any JavaScript framework. I was advised to follow the MVC structure. So I am considering these 3 ( Sails.js, LoopBack, NestJS). I get that sails is closest to rails, but that's not particularly a priority.

I just finished a web app meant for a business that offers training programs for certain professional courses. I chose this stack to test out my skills in graphql and react. I used Node.js , GraphQL , MySQL for the #Backend utilizing Prisma as a database interface for MySQL to provide CRUD APIs and graphql-yoga as a server. For the #frontend I chose React, styled-components for styling, Next.js for routing and SSR and Apollo for data management. I really liked the outcome and I will definitely use this stack in future projects.

We are starting to build one shirt data logic, structure and as an online clothing store we believe good ux and ui is a goal to drive a lot of click through. The problem is, how do we fetch data and how do we abstract the gap between the Front-end devs and backend-devs as we are just two in the technical unit. We decided to go for GraphQL as our application-layer tool and Prisma for our database-layer abstracter.

Reasons :

GraphQL :

1. GraphQL makes fetching of data less painful and organised.

2. GraphQL gives you 100% assurance on data you getting back as opposed to the Rest design .

3. GraphQL comes with a bunch of real-time functionality in form of. subscriptions and finally because we are using React (GraphQL is not React demanding, it's doesn't require a specific framework, language or tool, but it definitely makes react apps fly )

Prisma :

1. Writing revolvers can be fun, but imagine writing revolvers nested deep down, curry braces flying around. This is sure a welcome note to bugs and as a small team we need to focus more on what that matters more. Prisma generates this necessary CRUD resolves, mutations and subscription out of the box.

2. We don't really have much budget at the moment so we are going to run our logic in a scalable cheap and cost effective cloud environment. Oh! It's AWS Lambda and deploying our schema to Lambda is our best bet to minimize cost and same time scale.

We are still at development stage and I believe, working on this start up will increase my dev knowledge. Off for Lunch :)

Hi Friends, I am planning to create a web and mobile app for eCommerce purposes, which is very similar to Swiggy.com/Zomato. Started this app and created API using .NET Core, Entity Framework, and Microsoft SQL Server as DB. Consuming this API in Flutter for mobile and web UI. Just want some help and suggestions about this selection. Worrying about the application's scalability and performance, please suggest me a good architecture to create this application, which may be used by more people over a period of time.

I just finished the very first version of my new hobby project: #MovieGeeks. It is a minimalist online movie catalog for you to save the movies you want to see and for rating the movies you already saw. This is just the beginning as I am planning to add more features on the lines of sharing and discovery

For the #BackEnd I decided to use Node.js , GraphQL and MongoDB:

1. Node.js has a huge community so it will always be a safe choice in terms of libraries and finding solutions to problems you may have

2. GraphQL because I needed to improve my skills with it and because I was never comfortable with the usual REST approach. I believe GraphQL is a better option as it feels more natural to write apis, it improves the development velocity, by definition it fixes the over-fetching and under-fetching problem that is so common on REST apis, and on top of that, the community is getting bigger and bigger.

3. MongoDB was my choice for the database as I already have a lot of experience working on it and because, despite of some bad reputation it has acquired in the last months, I still believe it is a powerful database for at least a very long list of use cases such as the one I needed for my website

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.

Oof. I have truly hated JavaScript for a long time. Like, for over twenty years now. Like, since the Clinton administration. It's always been a nightmare to deal with all of the aspects of that silly language.

But wowza, things have changed. Tooling is just way, way better. I'm primarily web-oriented, and using React and Apollo together the past few years really opened my eyes to building rich apps. And I deeply apologize for using the phrase rich apps; I don't think I've ever said such Enterprisey words before.

But yeah, things are different now. I still love Rails, and still use it for a lot of apps I build. But it's that silly rich apps phrase that's the problem. Users have way more comprehensive expectations than they did even five years ago, and the JS community does a good job at building tools and tech that tackle the problems of making heavy, complicated UI and frontend work.

Obviously there's a lot of things happening here, so just saying "JavaScript isn't terrible" might encompass a huge amount of libraries and frameworks. But if you're like me, yeah, give things another shot- I'm somehow not hating on JavaScript anymore and... gulp... I kinda love it.

How Uber developed the open source, end-to-end distributed tracing Jaeger , now a CNCF project:

Distributed tracing is quickly becoming a must-have component in the tools that organizations use to monitor their complex, microservice-based architectures. At Uber, our open source distributed tracing system Jaeger saw large-scale internal adoption throughout 2016, integrated into hundreds of microservices and now recording thousands of traces every second.

Here is the story of how we got here, from investigating off-the-shelf solutions like Zipkin, to why we switched from pull to push architecture, and how distributed tracing will continue to evolve:

https://eng.uber.com/distributed-tracing/

(GitHub Pages : https://www.jaegertracing.io/, GitHub: https://github.com/jaegertracing/jaeger)

Bindings/Operator: Python Java Node.js Go C++ Kubernetes JavaScript OpenShift C# Apache Spark