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
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 5 years ago.
Improve this question
Our app is starting to become quite the monolith and seeing some scaling pain points. We have some long running page loads that kill the request queue for the rest of the app. Been thinking about it for a few days and have been thinking to abstract out to some microservices could release some pressure.
Been doing a lot of reading on microservices and have read you can have all your services share the same DB or create a new DB for each service - both are acceptable based on what I've read. Our data is quite large so it would be an easier abstraction to share the same DB.
I sat down this morning determined to start a new Rails JSON API app to abstract out some business analytics pages to a new service but quickly realized this new app won't have any of the model files etc in it for ActiveRecord to use. How do people get around this when they are sharing a DB with all services?
Edit:
I'm planning on this service to run off a follower read-only slave DB as well to help with the load.
If you use libraries like Sequel instead of ActiveRecord, you could rely less on the model layer and make your code/queries closer to the database, I don't think it would solve all your problems though as you would need to update your code everywhere after each migration. One thing you can do however, is package part of your model layer as Gems to share across applications.
"We have some long running page loads that kill the request queue for the rest of the app."
=> Can it be solved by making some of your requests asynchronous? The backend of the web app is not supposed to do any heavy lifting, it should be done by crons/other.
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.
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 7 years ago.
Improve this question
I've been working on a large website with Ruby on Rails for more than 2 years now and found it really convenient and easy to code a web application or service. Now I want to build a really thin web service: no DB, no front end 1-2 controllers with 2-3 actions each.
When I invoke rails new, it sort of "scaffolding" a large application structure, there is any way to get the default large structure replaced for a small service suitable structure with rails? (btw, If you think I don't need to use rails for such a project you're welcome to explain why. )
I was just going to upvote some comments, but we try not to answer in comments, so I'll try to synthesize the relevant points:
Rails' infrastructure is designed to accomodate a fairly complex app, and is probably overkill for the sort of simple app you're talking about building. This matters because Rails embraces Convention Over Configuration, and the conventions are geared toward larger apps.
Here's a couple of examples (not an exhaustive list):
Rails separates routes into their own file, with individual controller classes for interacting with each type of resource. If you have only a handful of pages in your app, this can be more structure than you need.
Although you can tell it not to, Rails assumes by default that you want to use ActiveRecord (and that you have a database for it to talk to). It also assumes you'll want model classes, and that there's both enough of them and they're complex enough that they need their own directory of individual files.
The Rails Asset Pipeline is great for dealing with lots of complicated assets that require extensive preprocessing. It's also kind of a pain in the ass.
There are a number of Ruby-based microframeworks that are likely better suited to the sort of app you describe. Sinatra is probably the most widely used. It makes few assumptions and is consequently lightweight, allowing you to establish whatever design patterns you want in your app. There are also bunch of others that might be worth considering.
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 9 years ago.
Improve this question
I just started with Ember.js and I can't seem to find a legitimate reason to use it in any kind of project, except for maybe a stand alone HTML5 application (not a website). That's just my opinion and know lots of people make use of it for good but isn't duplicating the ORM code on the client side a bit of boilerplate ?
There's a lot of discussion on "why Ember" elsewhere, so I'll keep this sorta short...
Ember and many of the other client-side MVC frameworks are best suited for applications that need to manage complex state changes between UI elements and their underlying data. Once you get to a certain level of sophistication on the UI, it becomes harder and harder to manage with data- attributes and jQuery dom finders. You can compare and contrast implementation of a sample application using different frameworks here: http://todomvc.com/
Ember is not duplicating the ORM layer. It does not do the actual persistence or integrate with your database, map the columns to the attributes, etc. It might feel similar in that you have JS objects that look similar to your models, but they serve a different purpose. They are meant to be data objects for your UI; almost the same as if you were going to produce JSON representations of your model for an API consumer; except these models can have behavior and can be bound to the UI (via controller) so that the UI stays in synch when the model data changes.
There's some good advice and opinion on Ember here (code syntax is outdated): https://github.com/trek/trek.github.com/blob/4bc36e47a9017bead7cbfd769d6dc87b57c8808d/_posts/2012-08-30-advice_on_and_instruction_in_the_use_of_emberjs.md
The Ember info out there (esp here and with the data interface) is a little difficult to navigate because a lot of the syntax has changed. This transition guide can help: https://github.com/emberjs/data/blob/master/TRANSITION.md
The Ember tutorials out there are also tricky because almost all of them assume that you are building an app from scratch and want your entire app to be based on Ember. This is a valid use case, but if you manage and maintain an existing app it's hard to visualize how to fit Ember into what you already have.
This tutorial has some good end-to-end info: http://hashrocket.com/blog/posts/setting-up-an-ember-app-with-a-rails-backend
This gist has some good ideas on how to incorporate ember into an existing Rails app: https://gist.github.com/eccegordo/7277817