I've created unmaintainable websites using PHP because it was so easy to do things quick and dirty. I don't want to do the same thing with Python/Django on Google's appengine.
Is there any good architecture references for creating websites using Django and appengine? (E.g. where to put business logic, where to put data access logic, how to cleanly separate the views, how to do unit testing, etc.)
Django by its nature will make it harder to put things in the wrong places. That is one of the cool things about the new generation of MVC frameworks, you have to work at it to create a ball of mud.
If you decide to not use Django, these hints from Werkzeug team might be interesting. This application structure takes what's best from Django but gives you complete freedom over actual layout (no need to have models.py even if you do not have any model in application...).
As already mentioned, by choosing Django, you have already taken a big step in avoiding spaghetti. Django provides you with an MVC framework (Model Template View to be Django specific). Thus, your job now is to study and properly follow the MVC design pattern which Django is guiding you with. Where you place your business logic will depend on your specific application and requirements. In some cases, some business logic is placed closer to the data in the models, and in other times its placed in the controller. Furthermore, GAE doesn't require Django and in some cases GAE's webapp framework should suffice.
Related
We are re-writing some of our web applications from asp.net MVC + jquery and angular in some places to asp.net web api (for now it's asp.net 4.6, but future plan is to have asp.net core here) + angular js. The main reason for rewriting is that we don't want html rendering on server side.
Now, some people want to have a NodeJS in between web api and angular js and some people cannot see any reason for having it (including me), it could be that no reasons are seen because of lack of knowledge about NodeJS, but my thoughts are:
If we have angular js + web api, why would we want to have something in between like a proxy (which is NodeJS in this case), and go through that proxy instead of going directly to web api? Is there any scenarios that cannot be done without node js in between which can be done with only web api? Our applications are simple: fetch some data from api and present it in ui. Some authentication is involved as well.
When having backend technology, one is enough, having two (web api and node) at the same time just adds complexity to application and is harder to maintan?
Should we or should we not use node in this case? Having in mind that in the team we do not have a lot of experience with NodeJS, but I hear these arguments that node is very easy to learn, so that's not a big problem.
This is not so much an answer as an extended comment because there isn't an outright question here.
Ultimately it depends on what the reason for wanting to use NodeJS are. To address your thoughts:
Why would you want a proxy
There are a couple of reasons for having a proxy, such as security and scalabilty.
For example, suppose you wanted to have your back-end implemented as a series of Micro services. Without a proxy, the client-side has to know about all of these service's endpoints to it can talk to them. This is exposing them to the outside world which might not be desirable from a security standpoint.
It also makes the client-side more complex since it now has to co-ordinate calls to the different services and you'll have to deal with things like CORS on the back-end; having the client side call a single proxy, that also acts as a coordinator, so it can "fan out" the various calls to the back-end services, tends to be simpler.
It allows you to scale them independently; some services might need to be scaled more than others depending on how heavily they are used. But the client-side is still hitting a single endpoint so it's much easier to manage.
Why multiple back-end technologies is not necessarily a bad thing
Having two or more back-end technologies is a trade-off; yes it can increase the complexity of the system, and can be more difficult to maintain, but it can also make it much easier to implement certain functionality where one technology is better at doing X than another.
For example, there are many NodeJS modules that do X, Y or Z which may be more accessible to you than corresponding functionality written in C# (I'm deliberately not going to list any examples here to avoid muddying the waters).
If you have Javascript developers who want to get involved with the back-end, they might feel more comfortable working with NodeJs rather than having to ramp up on C#/ASP.NET thus making them (initially anyway) more productive.
I find NodeJS really useful for quickly knocking up prototype services so that you can test how they are consumed, etc. Using something like HapiJS, you can have a simple HTTP API up and running with just Notepad in a few minutes. This can be really useful when you're in a hurry :)
If you take the proxy / microservices approach, you can stop worrying too much about what technology is used to implement each service, as long as it supports a common communication protocol (HTTP, Message Queues, etc) within the system.
Ultimately, you need to have conversations about this with your team.
You haven't mentioned if this is something that your peers are pushing for or if this is a decision being pushed by technical leadership; I would take the view that as the incumbent, any new technology needs to prove that there is a good reason for its adoption, but YMMV since this may be a decision that's out of your hands.
My personal recommendation in this case is, don't use NodeJS for the proxy; use ASP.NET WebAPI instead but look hard at your system and try to find ways to split it out into Micro-like services. This lets you keep things simpler in terms of ecosystem, but also clears the way to let you introduce NodeJS for some parts of the application where it has been proven that it is a better tool for the job than .Net. That way everyone is happy :)
There is a very good breakdown comparison here which can be used as part of the discussion, the benchmark included in it is a little old but it shows that there is not that much of a difference performance wise.
I am very wary of using an all-inclusive application framework for building my SPA. I have done a lot of reading on the subject, but I haven't found any articles on whether these frameworks are composable or not. I have a long-held architectural belief that frameworks should not try to do too much, rather they should:
do one thing only
do it very well
easily compose with other frameworks
Having said this, I'm trying to think outside the "should I use Angular, Ember, or Backbone" box and ask if there is a way to use more than one. For example, would it be possible to use Angular's templating (which I've heard is awesome) but use also Ember's routing (which supposedly rocks)?
My goal is to make the "all-important SPA framework decision" less important, so that I can change it later. If we go with a mixed approach, it buys us 2 major benefits:
we can rip out the "templating" engine or the "routing" engine or the "whatever" engine individually, and thus not need an entire application re-write to change something we don't like
by figuring out how to make them play nice together, we would be able to switch out individual routes/controllers/views allowing use to switch frameworks/approaches in small granular steps
Would this be a reasonable choice or totally fraught with annoying difficulties?
If the answer is the latter, then these frameworks are fundamentally flawed and I will not be using them.
The innards of both Angular and Ember are tightly coupled. You could do portions of a page with just Ember or just Angular, but mixing the routing/templating/data-binding from one framework to another would be an extremely difficult task.
am new to learning about MVC.
I am wondering if there is a heuristic (non programatically speaking) out there for dividing and deciding what logic goes on the front-end as opposed to the back-end especially when using front-end libraries like backbone.js.
That is, libraries like backbone.js separate data from DOM elements which makes it useful for creating sophisticated client side logic that, perhaps, used to be carried out on the server side.
Thanks in advance
Joey
The "classic" way to do Model - View - Controller is to have all three on the server. The View layer output of HTML and some JS is then rendered by the browser.
Rails is an excellent example of this.
The "new cool" way is to treat the browser as the main computing engine with the backend server providing services via APIs.
In this case, the Model, View and Controller software all run (as Javascript or coffeescript) on the client. Backbone is often a part of the browser-side solution but it has alternatives such as spine, angularJS and others.
On the backend server, you run the dbms and a good API system. There are some good frameworks being built on Ruby/Rack. See posts by Daniel Doubrovkine on code.dblock.org You have many choices here.
Advantages of MVC on the client
Responsive user interface for the user
Cool Ajaxy single page effects
Single page webapps can provide much faster UI to user than regular web sites
Good architecture, enabler for purpose build iPhone/Android apps
Depending on the app, can be used to create standalone webapps which work without a network connection.
This is what many cool kids are doing these days
Disadvantages
Need to decide on approach for old browsers, IE, etc
Making content available for search engines can be tricky. May require shadow website just for the search engines
Testing can be a challenge. But see new libs such as AngularJS which include a testability focus
This approach involves more software: takes longer to write and test.
Choosing
It's up to you. Decision depends on your timeframe, resources, experience, needs, etc etc. There is no need to use backbone or similar. Doing so is a tradeoff (see above). It will always be faster/easier not to use it but doing without it (or similar) may not accomplish your goals.
You can build a great MVC app out of just Rails, or PHP with add-on libs or other MVC solutions.
I think you're using the word heuristic in a non-programmatic sense correct? I.e. you're using it to mean something along the lines of 'rule of thumb'?
As a rule of thumb:
You want the server to render the initial page load for UX and SEO reasons.
You could also have subsequent AJAX partial page loads rendered by the server for the same reasons. Profile to see which is faster: having the server render and transfer extra data (the markup) over-the-wire vs. sending a more concise payload (with JSON) and having the client render it. There are tradeoffs especially if you take into consideration mobile devices where maybe rendering on the client will be slower, but then again there are mobile devices out there with slower internet connections...
Like any client-server architecture: You want the client to do things that require fast responsiveness on the client and then send some asynchronous operation to the server that performs performs the same task.
The take away is vague, but true: it's all about tradeoffs and you have to decide what your products needs are.
The first two things to come to mind for me were security & search..
You will always want to restrict read/write access on the server.
in most instances you will want to have your search functionality as close to the data as possible.
Is there an open source, reference implementation of a simple, correctly designed, best practiced, GWT + GAE open source application? I would like to see the best practices on the following:
Recommended GWT Page navigation, session handling
GWT best practice UI (validation, controls etc)
Work with detached objects, conversations, wizards
Effective and "as intended" integration between GWT and GAE
MVC implementation with GWT and GAE, where is the controller? (Spring?)
Using domain POJOs in the UI without writing data transfer objects?
JDO (or JPA) and DAO layer - correct mapping, transaction and service layers
A permission layer, (e.g. like Spring security/ACEGI)
Integration with client side libraries (JQuery / Sancha)
JUnit layer for both server and client side
All the samples I found so far handled a very narrow aspect of the above, and I'm sure there has to be one good "starting point" such as the one's you can find for Spring / Hibernate or RoR projects
Have you looked at Roo?
This can be used to quickly build a GWT app based on one of a number of JPA providers and databases.
It doesn't offer all the items listed but has quite a variety of optional add-ons
Unfortunately I don't know of any such reference implementation, and I don't think you're likely to find such an all-encompassing example is because:
It's much easier to understand an example that focuses on one thing, like focusing on using JDO in a GWT app, or using Spring security in a GWT app, or how to do client-side validation in a GWT app. There's no reason one sample has to include such disparate features.
In the same vein, what if I wanted this exact list of features in a reference implementation, but using something else instead of JDO? Should I expect someone to write everything all over again, with that one part replaced? It's much better to write samples and documentation for each piece of the puzzle and leave it up to developers to glue that knowledge together.
Some of the things you listed aren't exactly common usages, e.g., integration with JQuery and Sencha. That's not to say it's not possible, and there are some (focused) examples out there if you look, but it's not the main use case for GWT developers, so I don't think it makes sense in a reference implementation.
The sort of app you're talking about is very complex, something that would take multiple engineers months to write and then would have to be maintained and updated. All for a sample? Some people aren't willing to invest that kind of energy even when there's money involved!
That being said, there are some great GWT sample apps (with source available) here. Even though they don't encompass everything you listed, they'll hopefully be helpful.
There is a "Google App Engine Java and GWT Application Development" A code of the application they build during the book comes "Licensed under the Apache License, Version 2.0" so (I guess this is qualify as open source but IANAL) it worth looking at. At least it does helps me as I am working through the same set of questions. It written Nov 2010 so it is still relevant as Google Platform evolves at astonishing speed.
Declaimer - I got no relation to this book except that I am reading it.
A client wants to have a simple intranet application to manage his process. He runs a query and wishes to track number of loads delivered per day and associated activities.
Since I knew about Django's excellent Admin interface, I figured I could define the "Schema" in models.py and have Django Admin generate the forms.
I did exactly that and the result is not bad at all. I've been able to customize the look and feel to suit the client's taste.
Some questions:
Is Django Admin the right choice for such a use-case?
Will I run to problems in the future due to flexibility of the framework?
Is there a better framework out there specifically designed for this use-case (general Database management for small businesses)? I prefer ones written in Python since I can hack it up to customize.
Thanks!
In my personal experience, Django is a good choice for just being able to have a nice-looking UI on top of a database.
There is a chance you could run into flexibility issues trying to customize the admin interface... however, using Django's ModelForms and Templates - it is easy to create your own CRUD application - if you can't do what you need in the admin interface.
As far as Python frameworks go, I personally prefer Django over Turbogears or Pylons (which I believe also have admin interfaces) because it seems much simpler to get installed, setup and running.
Again, that is just my personal preference. ymmv.
I've been tempted to do something similar, and the answer is that in general, you don't want to hack the admin interface, because that's not it's purpose, and sooner or later you'll run into some flexibility issues.
Check my Q: How to implement a client admin in Django?
Having said so, I'd stick with django.