Hi, Which tool will you recommend:
I need to build a web application, oriented to small businesses, like a small ERP. It will have intensive use of Sql to access a PostgreSQL database. It has to be secure, as it will handle information on customers, sales, inventory.
If you think another tool will be better, please let that know.
Thanks a lot
Looking for Advice! I am developing a hybrid app for video streaming, I have a prior experience with .NET Core and would like to use it for my back end but the latest buzz on characteristics of Node.js such as light weight, event loop and Async capabilities is really tempting me to reconsider my decision. On a quick research I could observe that a lot of Internet companies use either Python Django or Node JS for their back end which has thrown me into confusion, looking for an expert advice, thx.
So none of these tools may be bad for your implementation of this streaming app. But one thing to consider is what are you trying to achieve. If your application is more front end facing with streaming to a backend service C# may be your better implementation path just due to its greater overall versatility in terms of options for mobile, backend development, front end development, service development, etc... However if your focused purely on the streaming aspects and utilizing Amazon or Azure services in conjunction with the language of choice, Python, Node.Js, Django or other technologies may offer a faster option to success. Another thing to consider is many of the streaming platforms today utilize services from cloud vendors to achieve their success more than simply the ingenuity on the part of their internal staff's programming skills. Traditional programming languages like Java, C++, C# are used less these days. Today most teams are piggybacking off these services where its possible to give your application the greatest ability to compete with the big boys. - Your Friendly Neighborhood Tech Manager
You could apparently go for both Node or Django but I would recommend choosing Node as you're building a video streaming app and the biggest video streaming service Netflix used Node in the production.
What will be better Laravel or Node.js to handle a logistics portal which displays thousands (20-50k) of delivery data information in an interactive table (searchable, filterable), live delivery tracking, basic user management, and report creation?
Data comes usually in CSV (manually uploaded or via API from courier companies). Live tracking uses checks tracking numbers on the courier page using API.
We choose Next.js for our React framework because it's very minimal and has a very organized file structure. Also, it offers key features like zero setups, automatic server rendering and code splitting, typescript support. Our app requires some loading time to process the video, server-side rendering will allow our website to display faster than client-side rending.
I was considering focusing on learning RoR and looking for a work that uses those techs.
After some investigation, I decided to stay with C# .NET:
It is more requested on job positions (7 to 1 in my personal searches average).
It's been around for longer.
it has better documentation and community.
One of Ruby advantages (its amazing community gems, that allows to quickly build parts of your systems by merely putting together third party components) gets quite complicated to use and maintain in huge applications, where building and reusing your own components may become a better approach.
Rail's front end support is starting to waver.
C# .NET code is far easier to understand, debug and maintain. Although certainly not easier to learn from scratch.
Though Rails has an excellent programming speed, C# tends to get the upper hand in long term projects.
I would avise to stick to rails when building small projects, and switching to C# for more long term ones.
Opinions are welcome!
I am planning to develop project management system SAAS based. Can any one help me with selection of platforms from Django or Laravel and for database MongoDB or Firebase/Firestore or MySql? On front end I am going to use Quasar Framework (VueJS). Note : project will be Webapp, Mobile app and desktop app.
Sign up to add or upvote prosMake informed product decisions
Sign up to add or upvote consMake informed product decisions
What is Laravel?
What is Node.js?
Need advice about which tool to choose?Ask the StackShare community!
Sign up to get full access to all the companiesMake informed product decisions
Sign up to get full access to all the tool integrationsMake informed product decisions
Red Hat, Inc.
I moved from .NET and Rails to Laravel, and since then never thought to go back. I feel Laravel framework has the capability to overcome all modern frameworks.
At Soft Pyramid we are developing rich business applications using Laravel Framework, and never feel any limitation even for complex reporting.We have written REST apis, complex ERP solutions and found awsome in all areas.
I have benchmarked Node.js and other popular frameworks using a real life application example. You can find the results here: https://firstname.lastname@example.org/web-rest-api-benchmark-on-a-real-life-application-ebb743a5d7a3
The first live version of Leanstack was actually a WordPress site. There wasn’t a whole lot going on at first. We had static pages with static content that needed to be updated manually. Then came the concept of user-generated content and we made the switch to a full on Rails app in November of last year. Nick had a lot of experience with Rails so that made the decision pretty easy. But I had also played around with Rails previously and was comfortable working with it. I also knew I’d need to hire engineers with a lot more experience building web apps than I do, so I wanted to go with a language and framework other people would have experience with. Also, the sheer number of gems and tools available for Rails is pretty amazing (shout to RubyToolbox ).
I don’t see us ever having to move away from Rails really, but I could be wrong. Leanstack was built in Rails 3. For StackShare we decided to upgrade to Rails 4. Biggest issue with that has been caching. DHH decided to remove the standard page and action caching in favor of key-based caching (source)[http://edgeguides.rubyonrails.org/caching_with_rails.html#page-caching]. Probably a good thing from a framework-perspective. But pretty shitty to have to learn about that after testing out your new app and realizing nothing is cached anymore :( We’ll need to spend some more time implementing "Russian Doll Caching", but for now we’ve got a random mixture of fragment and action caching (usually one or the other) based on which pages are most popular.
We use Rails for webpages and projects, not for backend services. Actually if you click through our website, you won't notice it but you're clicking though, I think, seven or eight different Rails projects. We tie those all together with a front-end library that we wrote, which basically makes sure that you have a consistent experience over all these different Rails apps.
It's a gem, we call it Karmeleon. It's not a gem that we released. It's an internal gem. Basically what it does is it makes sure that we have a consistent layout across multiple Rails apps. Then we can share stuff like a menu bar or footer or that kind of stuff.
So if we start a new front end project it's always a Rails application. We pull in the Karmeleon gem with all our styling stuff and then basically the application is almost ready to be deployed. That would be an empty page, but you would still have top bar, footer, you have some custom components that you can immediately use. So it kind of bootstraps our entire project to be a front end project.
We decided to move the provisioning process to an API-driven process, and had to decide among a few implementation languages:
- Go, the server-side language from Google
We built prototypes in both languages, and decided on NodeJS:
- NodeJS is asynchronous-by-default, which suited the problem domain. Provisioning is more like “start the job, let me know when you’re done” than a traditional C-style program that’s CPU-bound and needs low-level efficiency.
- NodeJS acts as an HTTP-based service, so exposing the API was trivial
Getting into the headspace and internalizing the assumptions of a tool helps pick the right one. NodeJS assumes services will be non-blocking/event-driven and HTTP-accessible, which snapped into our scenario perfectly. The new NodeJS architecture resulted in a staggering 95% reduction in processing time: requests went from 7.5 seconds to under a second.
The server side of Trello is built in Node.js. We knew we wanted instant propagation of updates, which meant that we needed to be able to hold a lot of open connections, so an event-driven, non-blocking server seemed like a good choice. Node also turned out to be an amazing prototyping tool for a single-page app. The prototype version of the Trello server was really just a library of functions that operated on arrays of Models in the memory of a single Node.js process, and the client simply invoked those functions through a very thin wrapper over a WebSocket. This was a very fast way for us to get started trying things out with Trello and making sure that the design was headed in the right direction. We used the prototype version to manage the development of Trello and other internal projects at Fog Creek.
All backend code is done in node.js
We have a SOA for our systems. It isn't quite Microservices jsut yet, but it does provide domain encapsulation for our systems allowing the leaderboards to fail without affecting the login or education content.
We've written a few internal modules including a very simple api framework.
I don't know how well this will scale if/when I have hundreds of people connected simultaneously, but I suspect that when that time comes, it may be just a matter of increasing the hardware.
Used node.js server as backend. Interacts with MongoDB using MongoSkin package which is a wrapper for the MongoDB node.js driver. It uses express for routing and cors package for enabling cors and eyes package for enhancing readability of logs. Also I use nodemon which takes away the effort to restart the server after making changes.
Web has always been in Rails from the beginning, so we used Redis for caching our items, which we had, from the beginning. Rails is kind of what we were comfortable with, and we knew we wanted the front end to be really, really snappy, so we de-normalized all the item attributes into Redis, and that's how it got served out.
Rails 5 (beta 3) provided a nice structure for rendering responses, linking to front-end assets (compiled previously via Webpack), handling sessions w/ tailor made login links via an email button/token, background jobs, and creating an admin behind basic auth to allow managing of users and purchases.
For this project rails was ideal due to new features introduced in Rails 5 that allowed us to build a lightweight "API only" project. Developer familiarity and the ability to rapidly iterate, as well as providing an accessible testing framework were additional factors.
The best PHP framework right now, intuitive and growing up quickly.
We use Laravel in the outer layer of our Clean Architecture codebases, whereby the domain model does not rely on the framework as a whole.
See "PHP", I don't really choose to use it, but I can step in and operate in Laravel when necessary. Same goes for quite a few other PHP frameworks, including my own full-featured proprietary stack.
An excellent PHP framework employing SOLID principles to rapidly develop web-site systems and connect them to databases. Custom development of admin screens for website management.
A clean, easy to understand, well documented framework with excellent tools and a great community providing every imaginable extension to add functionality to your project.