Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I'm in the middle of architecting a Grails 3 app based on the microservices project structure. Based on Jeff Scott Brown's video on how he separates the Web UI and the backend by using two Grails apps, isn't the Web UI app an overkill, compared to using an AngularJS based html?
Please do point out the benefit of using a Grails Web UI app if any.
I know it is one year later, but since I wondered the same here is my conclusion.
The presentation of Scott Brown misses the point of micro-services. They are not just small pieces of code that provide a RESTful interface, but they are defined as micro, by their footprint and the fact that they can live separate from each other. Try running a Grails instance for each small service. The cost will be huge as each machine requires more than 1GB ram.
To answer your question; monolithic frameworks as Grails are great toolkits, making it easy to handle and maintain more complex logic, as well as handle security and other common tasks which with (e.g.) Node you would need to install libraries of dubious quality or implement them yourself.
My take on the general aspect of micro - services or monolithic frameworks is that if you need simple data access and you are worried about scaling or you need a flexible way of distributing then use micro-service frameworks. If you have a complex business model or you need to use the tools in the framework use a monolithic framework. Finally, don't forget that no one is stopping you from using both simultaneously if needed be. It's a valid strategy.
I suggest watching Martin Fowler's "Microservices" talk.
https://www.youtube.com/watch?v=wgdBVIX9ifA
I guess this architectural approach is now a bit outdated with http://micronaut.io beeing available.
But however, as I do understand, you ask mainly if you shouldn't use an Angular or React frontend instead of the server side rendered Grails UI.
So this depends. Angular and React perfectly fit the requirement for a single page app, but sometimes all you need is a good old HTML frontend. And even if you decide to use a javascript based frontend, you often need a backend for frontends or API manager as entrance to your microservice world. A Grails UI can serve this need perfectly.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I wanna understand the extent of node js?
Is it used only for mobile web apps to handle server side or can it be used to develop a full fledged web app for all device configuration(like replacing ruby and rails).
I found some examples but all seems to be mobile web apps.
Is it like companies like
Aibnb,
Linkeddin... etc
developed two sites, one with nodejs as backend and other with ruby and rails and depending on the device they route to that site.
Please give me some favourable inputs so that my confusion can be calmed.
Node.js is not just for mobile apps. This question How to decide when to use Node.js? gives a good analysis of when to use nodejs.
But, to sum up a bit:
Node is good when you have a lot of short lived requests that don't require heavy CPU processing.
Node is good if you want to use all javascript
One disadvantage with node is that there are a lot of javascript packages that do similar things - the environment isn't as mature or as standardized as other languages (maybe this isn't a negative to you though)
Mobile applications often lend themselves to using node because they often follow the pattern of many short lived requests, e.g. look up something from a database.
There are tradeoffs, such as as that you will be using a fully dynamic language across your entire stack (not for the weak at heart).
So to recap, node is not just for mobile apps, but you should do some research to understand why you might use node.
Node can be used to produce many more solutions than just providing for mobile devices. Some solutions include command line tools (ex. Grunt), applications (ex. crawler), web services (ex. RESTful services), and full-fledged web sites (ex. hummingbird). Lastly if you want an example framework for constructing standard HTML (desktop or otherwise) web apps in node, see Jade.
As to which framework a company chooses often there are several APIs provided. As their web services communicate with standard XML or JSON documents, communication between servers doesn't necessary need to be written in the same language.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm considering using Node.js with a framework such as express, meteor, or sails (a directory with social features such as sharing, messaging and uploading media). I don't have any features planned that explicitly require real-time functionality, so does it make sense to use Node.js anyway instead of Rails?
There's so much buzz around Node.js that I am tempted to use it just so that I don't get left behind.
As DHH wisely noticed regarding Node vs Rails, "everything can be used instead of everything else". That's somewhat true in a sense that, for example, a site in Rails with promptly set up caching can be as fast as one written in Node.js.
Besides, Node is not necessarily about real-time. It's more about being able to handle many light (in terms of processing time needed) requests. If you expect high level of concurrency (I mean, really, expect, not just are dreaming of it) and every request is supposed to be relatively small, then you could consider using Node, just because handling bigger load (up to some point) will require less work with Node.
Bottom line, use what you are good at. Unless you want to try something new. And Node.js is definitely worth trying.
You're question does lack quite a bit of context.
This question all depends on the context.
If this is contract work or something you want to make money with in the near future and you're not sufficiently skilled with any of the mentioned nodejs frameworks.
Then I would recommend you use whatever you're already good at.
If this is a private project for fun or any other non serious purpose.
Then I would seriously recommend you to try one of mentioned nodejs frameworks.
In my opinion nodejs is currently the cutting edge web technology. As a developer
you should always try to stay on the cutting edge. That way when you learn how nodejs can be used you might find ways to use those things in your professional environment.
I've lately been using meteor a lot and I can highly recommend it, once you get the hang of it you can do truly amazing things that you could never even imagine doing(in a reasonable timespan) in a classic php project.
Also according to some meteor will replace RoR alltogether blog
Aside from real-time, main plus I've seen is having same team being able to develop JavaScript client code and server side code for UI web applications. "Code sharing" between client and server seems a pipe dream to me, but same language is really nice.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I'm building a pretty stock standard N-tier ASP.NET MVC website, and I'm trying to think of all the little miscellaneous tasks that people often forget to do when building a site.
Off the top of my head things like:
Custom error pages
Maintenance downtime handling
Load testing
etc.
What are the common things that people often forget?
People tend for forget to test the deployment and upgrade process.
Deploying the system to a production-like environment early on during the development process will uncover (often forgotten) external dependencies and configuration settings that need to be tweaked before production. Plus it will force the team to start thinking about the upgrade process and how to automate it.
Some examples of such tasks (from my own experience):
make website running well with javascript disabled
forms validation (especially limiting size of the input)
protection against CSRF and other kinds of attacks (penetration tests)
logging server errors (using elmah or sth similar)
make web site logo displaying on the address bar
SEO optimization (meta tags, page keywords, descriptions, sitemap etc)
Edit: added point about javascript.
In my experience the main mistake or misunderstanding of people starting using MVC is that they confuse the C of MVC, the Controller, with the Business Logic and the M, Model with the Data Acess Layer or entity model.
I have given this answer a while ago and there are some comments about this confusion of the fact that MVC is only about UI controlling and modeling, it's surely not replacing other NON UI related layers... MVC3 and Entity Framework
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I've just been redirected by a firend on the uniGUI website. In a previous question I asked about a comparison between Raudus and ExtPascal.
Now this unigui seems to be an alternative to Raudus, that moreover has the advantage of allowing you to compile the win32 exe at the same time with the same source code (of course if you limit yourself to use only uniGUI approved UI components).
I think this is amazing, even if this idea at a first sight willnot make happy all the web apps purists, but in my opionion having this kind of tool is great.
There are many (even small) applications, that can benefit for this code once, get a double UI.
Anyway which are your feelings about this? Do you think it has a future?
ADDITIONAL NOTE: In order not to start a general discussion please try to answer by mentioniong uniGUI specifically, not only a general answer. Thanks.
I started developing uniGUI (or whatever name it may adopt in future) around two years ago. Since then it has evolved a lot. Initial version was based on VCL for the Web. With addition of ExtPascal and Ext JS it has become a very advanced tool to develop Web apps based on Delphi.
uniGUI simply defines itself as a Web Application Development framework. The concept of Web Application has been controversial since its first inception. Some people claim that Web is stateless but applications are statefull, one should not mix these two. However, nowadays with an increasing demand for web applications such notions only remain as a philosophical point of view.
More and more people want to access their desktop apps from the internet. Companies want their local accounting software to be accessible to other branches. A security company wants a web gateway for their access control software. These are all examples for the increasing demand for web apps.
We can consider uniGUI as an abstraction layer for Delphi VCL controls which extends them to the Web. Like all other abstraction layers it helps developer to focus on application logic rather than the development tool itself. It tries to fully integrate the RAD approach into Delphi based Web development.
Dual nature of uniGUI is simply a plus. I'm referring to its ability to deploy same application to both web and desktop using same codebase. This feature maybe useful for some developers but useless for others and it can be completely ignored by those who focus on Web development only.
As for the scalability, the best target for uniGUI and other similar tools seems to be the intranet where the number of clients are predictable and connection speed is a non-issue.
That said, nothing prevents developers from developing web apps that target the internet. At end it is all Ext JS on the client side and Delphi event handlers on the server side. It all depends on how smart you design your app and how efficient you manage your resources. If each of your sessions consumes 10 MB of memory then you're likely to run out of memory very soon.
In conclusion, this framework will have a group of users which will find it best for their needs. There is no black or white here only big gray areas. Like any other tool it depends on the company, the particular project and the available deployment options to see if it is the right tool for you or not.
Web applications are very different from GUI ones. Mixing two approaches for something
more serious then simple form or several buttons I think is just wrong.
I think that the UniGUI idea is a great one. But I think that Embarcadero is the one that should offer that as one more option for developers instead of a independent one. Delphi developers always wanted an easy way to create web applications, and sincerely WebBroker is very poor.
Anyway which are your feelings about this? Do you think it has a future?
The general idea definitely has a future, if only in the PT Barnum sense. This particular implementation doesn't seem to be anything special - there's nothing in it that grabs me as being a great solution to any of the problems I currently have to deal with. But then, I see thick client apps, especially traditional Delphi 2 tier apps, as quite different from web apps.
I'd be more interested if uniGUI worked the other way, and provided a solid MVC framework for Delphi, then extended that to the web. That way you could more easily have your data + business logic + GUI in three connected pieces, rather than the traditional Delphi/RAD problem that business logic gets all tangled up in the GUI, then the web application is a pain to develop because the layers "have to be" separated. This smells like "solving" that problem by letting you leave the business logic mixed into the GUI when you move to the web.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 months ago.
Improve this question
My company is looking to move their software to an open source framework. Their first thought was J2EE. I know that Django and Rails are popular for recreational development, but not sure about them in a corporate setting.
I was looking to compile a list of possible web frameworks to consider. Unfortunately I am not able to release our requirements to the public. Also I would like to know if you have seen/used different frameworks in a corporate environment.
Thanks
I believe the more important question is what talents you got. If you have a primarily Java team, and you want to completely move to Ruby or Python, it's gonna be hard, if not impossible.
When deciding if X language/framework is good for a business, you have to consider opinions from your internal technical staff first. That normally sets you in a place with limited choices. Unless you are with a very small but highly talented/motivated team or planning to build a team with new hires.
Not sure what you mean by a corporate use, but we're using Django at a large media company for the websites of nearly 40 radio stations.
Another vote for Django. I'm not sure if the Washington Post or LA Times count as "corporate" but they have a lot more demands (both daily hits and time-to-new-feature) than your average "corporate" environment.
Struts, Stripes, Wicket, Spring MVC. I use Grails and love it.
You can go to Rails too. We use Rails successfully in a number of serious applications.
If you are just looking to save money from software, you can go to any J2EE frameworks out there. If you looking for some fun and rapid development, try Rails.
It all depends on the type of the project and the talent you have.
I use django in a real-time professional environment.
it's solid, and blazing fast (django on nginx/fastcgi, and soon couchdb too!)
We're using sinatra (ruby) for frontend to our main internal application. Simple, stable and flexible.
Struts2, Spring MVC, Stripes, Wicket, Grails, JSF, Seam, GWT, Flex, etc (Stripes and Grails being my favorite).
Matt Raible did interesting comparisons of (most of) them in this presentation which is an updated version of this old one.
Another interesting reading might be the What is the most commonly used Java web framework? question here on SO.
IMO, whatever you choose doesn't matter that much, the presentation layer will still be throw away code.
Any framework that keeps you away from the imperative languages (e.g. Java, C#, JSP with Java etc.) is better. Declarative/Functional/Data Flow languages (e.g. Ruby, XSLT, Python, etc.) result in solid implementations that save you support/enhancement $$$.
It sounds like the powers that be are comfortable with Java, but do yourself a favor and avoid J2EE. Go grab Restlet and Groovy, write a nice Rest back-end that not only serves as a programmatic API for your project, but will work nicely with any Ajax/Javascript library you choose to implement a UI in.
We are currently using Django and the web site is driving a lot of business to the company as well as growing by double digits since last year. It doesn't matter what kind of technology the corporation is using but what their business model is. What are you currently using in-house? It will make more sense to use a web framework related to your in-house code, knowledge and man power.
If nobody knows Rails or Django, you have to factor in the learning curve during the migration. It should only be a couple of weeks depending on the savviness of your developers. Then again if everyone hates or do not enjoy working with the in-house technology, trying a new one might be worth it.
"I know that Django and Rails are popular for recreational development (...)"
Rails:
http://basecamphq.com
http://highrisehq.com
Django:
http://www.lawrence.com/
http://www.everyblock.com/
They have high traffic and content-heavy services. I wouldn't call those guys business as "recreational development".