You want your application to have the speed and power it needs to serve its purpose. If it becomes sluggish, you could lose users.
There are many factors that go into performance, but size is the main one. When apps are small, Sinatra tends to perform at a higher rate of speed. However, as they grow, Sinatra has a hard time handling the load. This isn't due to Sinatra itself, but instead it's because not many developers have the experience to build scalable components manually. Whereas Rails lets you offload different actions in order to keep the application running smoothly.
From creating background jobs to ETLs, you can ensure that your Rails app keeps up the speed. In like manner, when I'm building an application that utilizes a microservice based architecture or a JavaScript MVC framework, Sinatra performs very well due to its lightweight nature. Take these various factors into account when choosing between Rails and Sinatra. I've been a software engineer for the past decade and have traveled the world building applications and training individuals on a wide variety of topics.
With Rails you can get to production real quick and fast. The JavaScript community is on its moment, growing and gathering more people everyday but the Rails community is also a big one and there's always going to be a Rails developer to hire whenever you're ready to hire someone. I suggest you to go with Rails because is a good choice, gives you less things to worry about and it's a very good and mature framework.
I need a solid argument to explain to people that aren't necessarily tech-savvy as to why we should choose Rails over Nodejs. Hi Max, it sounds like that you are proficient in both stacks and probably have a higher expertise in Rails correct me if I am wrong and since you are the only dev on a project, a good argument that comes to mind is probably the velocity and maturity enterprise grade, battle tested in production that Rails provide with proven success stories in the tech industry such as Airbnb, Stripes, Shopify to name a few.
You can also build and show a prototype using both and share your experience which could help you find and forge the selling points to those non tech savvy folks, why not. Eventually, are you going to have other developers on your project?
IMHO, I am not a fan of the debate Rails vs Nodejs, they are just tools at the disposal of the developer it's just a matter of figuring out what makes the most sense. Rails has advantages over node. While Express has some speed advantages to Rails, this is mitigated if your software is more CPU intensive. Hi Community! Trust everyone is keeping safe.
I am exploring the idea of building a Neobank App with end-to-end banking capabilities. In the process of exploring this space, I have come across multiple Apps N26, Revolut, Monese, etc and explored their stacks in detail. The confusion remains to be the Backend Tech to be used? What would you go with considering all of the languages such as Node.
As a general trend, I have noticed the usage of Node with React on the front or Node with a combination of Kotlin and Swift. Please suggest what would be the right approach! Use the language which works well for the developers you have or have available. If you're starting, building a first iteration is far more important than worrying about what language might be best to solve a problem you may never have. When hiring, look for developers, not "node developers" or "java developers" having people who recognise and are willing to adapt means you can have the flexibility you will need to solve as-yet unforeseen issues.
Hire people who are wed to a specific language and you will be bound to that language, regardless of whether it's most appropriate or not. For online banking, it'll be less computation intensive and more data intensive. So, Rails will be better than Python. I'll not recommend Node.
If I had to choose indepently I would took Go. Typescript reduces many errors and makes potentially big app more maintainable. For banking app typed language is must have, so if not node than it could be anything typed, but not python or ruby. Also you can search benchmarks by yourself - ruby is the slowest language in the world, python comes next, javascript is on top of interpreted languages by speed. HI Shivam, If you the only person who is going to develop the full application then I will suggest you to go for Node.
And if you are thinking about scaling then do not worry. Nodejs with mongodb make good application. Capital One bank, Paypal, Linkedin and so on companies shifted themselves to Nodejs. Even if you go for Ruby, it has GVL which again makes it work in single thead. If we talk about the deployment of Nodejs, it require less resources as compare to other. I have deployed inventory solution right now using Reactjs with Node.
I have also deployed apps in Ruby as well. However, node is fast as compare to Ruby and you can scale it easily.
I am not saying Ruby is bad. I work in Ruby as I told you above. But these are the real facts. Since it's a banking app, I'd advice you go with Python for the backend because of the data analysis you'd be doing in your app.
I see you doing some data analysis since it's a banking app. Python is a powerful language for data analysis. Don't even try going hybrid for this kind of application. It's best going native. The reason why companies are switching to nodeJS is because it unifies all development under a single language. If you are a one man team you can start developing anywhere on the stack without the overhead of switching languages at each layer. If you have a large team, your DBAs, your core service team, your application team can all read each others code.
If you need to optimize performance for mobile further you can contract an iOS Developer to build in Swift or an Android developer to build it Kotlin and give them keys to use your nodeJS apis. As others mentioned, the problem domain is around data. From my experience, data means strongly typed entities. An alternative or addition to all of the above is the use of 'strong protocols', such as Protocol Buffers, Avro, Thrift and the likes.
In this case you get type safety and stability between communicating backend services, while deciding and changing on whatever backend service language you want. That goes to say that your problem is not related to programming language decision but to a much profound understanding of what's important for the business to be created and be valuable. As a general note, I don't think you should go, if you've got commercial aspirations, with any language that you'd have hard recruiting people who actually know what their doing.
In Israel it would mean take Kotlin out of the equation. You should not go with react,kotlin and swift those are very colourful languages but java ,node. You should only go with kotlin if you want to use android studio it is highly compatible. So its your choice. Rails::API was released in the spring of Rails::API started as a stand-alone gem, but with the release of Rails 5 in the summer of , its now included by default in Rails.
There are other alternative web frameworks in Ruby but their usage is significantly lower than Sinatra. For simplicity, we won't discuss those in this article. Let's go over some questions that can identify which framework might be the best fit for your scenario. If you are building a simple web app, you may think you don't need the special sauce that Rails provides.
However, just like peeling away the the layers of an onion, you start to realize that even simple apps require decisions that Rails has already made for you. For example, if you choose Sinatra or Grape for an initial version of an app, you'll need to think about:.
In short, when you don't go Rails, you'll need to make some decisions and have some opinions. If you are building an app as part of a team, this can add a layer of complexity and differing opinions on direction that don't exist with Rails' configuration-over-convention approach. For these reasons, I typically suggest starting with a Rails app and breaking out services when there's a clear need and scope.
However, if it's possible your app could grow beyond simply returning JSON responses ex: render HTML content, have interactive forms, users sessions, etc you can rule out Grape. Thanks to Rack's support for mounting apps, you aren't stuck with a rewrite if the scope of your app changes and your chosen microframework begins to get outside its sweet spot. You can easily mount Grape and Sinatra apps within a Rails app, or even mount a Grape app alongside a Sinatra app.
Grape emerges as a clear choice when you outgrow a roll-your-own approach to an API.
0コメント