I'm building a POS(Point of sale) web application using Django for my client. This is a single instance web app.
I just want to know, should I build APIs to separate Backend and Frontend?
Whare are the benefits to build the APIs?
First and most importantly, each design decision you take for your application should be for a reason. There is no good or bad approaches, however, the approach you decide on should be based on your use-case.
I don't see any problem for having a monolithic Django application to service a single/multiple POS with limited number of users. Tens of thousands of Django applications out-there not using APIs and performing well.
That being said, if you are developing a POS solution and planning to offer it to public as SAAS (software as a service), then you might need to consider using APIs, have plans for scaling/support/patching/monitoring/upgrade/ CI and CD activities. On the other hand, if might be planning to have a Mobile application in the future; That might be another good reason to have APIs.
Related
Me and some friends are going to develop a web site with playframework and a mobile application (android and iphone). So we need to make some webservices for the mobile application(CRUD). So we thought about using this web services in our playframework application instead of wasting time and creating the CRUD with anorm(writing all the sql requests).
Well, I'm here to ask for your opinion. Is this a good thing to do ? What's the best advised method here ?
Thank you.
PS: the web services are automatically generated with Netbeans from our database.
There are various reasons why I would advice against this approach.
A general design rule is not to expose your internal data model to the user. This rule comes in many flavors in which the layered architecture is probably the most known one.
In detail there will be issues like:
Tuning performance: This is hard to achieve because your have no, or not much control over the generated web services. When your application is really taking of your will suffer from this limitation
Access the service: I don't know whether you generate RESTful web services or WS-* ones. The latter will get you in trouble when accessing them via iphone.
Design Play vs. synchronous web services: Also somehow related to performance is the issue that the generated service is likely synchronous, blocking, which does not fit well with the non-blocking approach which the play framework is taking.
Abstraction level: Because your database is based on sets but your business model is likely not, you will have issues developing a decent client, tuning the performance, doing proper validation, security, etc.
Authentication, authorization and accounting: Hard to do because the database only knows the db system users
Change: What if you change your database model? Will the generated services continue to work? Do your have do adopt them event if you just add a column?
...
Some of those reasons do overlap, but I think the general problem should be clear.
Instead of this approach I would recommend the following. Develop a RESTfull endpoint for your app, which is not that hard to to. This is the external contract against which the clients should be developing. play-mini for example has a very need, Unfiltered based, API to do this. While doing this, focus on the operations your app really needs. CRUD in general is a bad model when thinking about production ready software.
How you access your database is another decision your have to make but probably it is not that important because it is not your external contract so your can change it when your have the need for doing so.
My company has created multiple enterprise applications over the past 15 years that now needs to gradually migrate to the web. I've created a pilot app using Django showcasing it's powers and how each legacy app can be converted.
For now the MVC architecture was the best solution proposed. Among the other architectures was a full Java stack that made use of JBPM for it's workflow management which my boss needed and asked if we could somehow make use of JBPM and preferably not some other BPM - 'cuase of it's powers.
The idea is to create multiple Django powered applications that each work on their own and then use JBPM to connect some of the Django services/views together in a workflow manner.
The question is can this be done?
I don't see why not:
Django can interact with webservices -- which is what you could use in order to interact with jBPM from the Django applications, and vice versa. A quick google implied that web services were easy enough to implement in order to interact with a Django frontend (from jBPM in this case).
I have a specific question about Java EE architecture. I have an application that requires several components:
A web service and persistence layer (cxf/hibernate)
A management / configuration console (Struts2/JSP?)
One or more user "applications" (Maybe Vaadin?)
Note, the web service will provide services to the user applications.
The web service has been built as a cxf/glassfish application (Eclipse dynamic we app) and is working well.
Should the management and user applications be developed as entirely separate applications (EJB's or ?) or form part of a "single" application with the web service. I am not sure if I am explaining this well enough - but I am new to this sort of design and am trying to approach the solution in a well structured way. For example I could imagine that taking an approach of separate services (applications) could result in:
Primary web service (does common data persistence stuff)
Authentication service
Management App service
First user App service
Second user App service
Each of the user apps is likely to have both common and unique data persistence requirements.
To decide how to split your implementation, you should consider your system through different views. In software architecture, there is a very useful method which is called the 4+1 architectural view model (http://en.wikipedia.org/wiki/4%2B1_architectural_view_model). Using the Physical view you will be able to decide if you may need to install the different components in different machines, and this will help you to define your development view, that will give you the answer to your question -> how to split the different components of your system in a development point of view. Once you have the development view, you can define how the components communicate (process view)... and so on.
This views have always helped me, I hope you find it useful.
I am in process of building a web application + Mobile application (Android and iPhone to begin with). I know the functionality and can write functional specification. I haven't decided whether I should be build native apps or a mobile web app.
Since I will have a reusable functionality (used by web app as well as mobile apps), I should exposed core functionality as web services and consume it from views (Mobile, Web UI etc.)
My goal is to build faster. Application/platform should scale up well in future. I am low on budget, so am looking for open source or low-licensing fee stack (Java, LAMP, open source etc.).
I need suggestions on technology stack. Also if you have similar experience, let me know your experience.
Thanks a bunch.
I work on similar solution, ie. web-app + API + mobile apps and use:
Server side: Python + Django + Piston (for making REST API).
Client side: Native iPhone app (Android in the future)
I'm satisfied with my choice. Django allows to develop fast. Python is very expressive and quite fast (in terms of dynamic language). Piston lets you create REST API easily. All of these are free, of course.
Considering iPhone - a native app was a requirement, so I wasn't thinking about building mobile web apps.
It very much depends on the type of application you are talking about. From my company's experience and from listening to others, the choice whether to use native app or web app or hybrid app depends very much on the functionality you need to include.
One thing is logic, another is presentation.
Logic can usually reside on the server, but in case you need to work offline as well then at least some of this has to be done on the client. Then even if it is offline - you should decide if it is web app or native logic, but developing a web-browser complex offline logic which will be cross-platform might be more difficult sometimes than writing it twice natively. Really... So if offline is needed, I'd lean to native logic anyway. Otherwise you might think about appcelerator, but you will have big learning curve if you are used to web development. They say they are html + javascript but only about syntax - you have to learn the whole stack anyway.
Presentation - if you require simple list display with not a lot of graphical effects, not a lot of many pictures to browse through with simple few buttons, tabs, web is good to go - jquerymobile, phonegap are your friends there - phonegap especially if you need access to phone functions like camera or contacts. But if you need at least some level of smoothness, good user experience and something of a "wow" effect for the user there is no other way than a pure native applications - android and ios developed by joined multi-platform team (share concepts are more important than shared code IMHO).
For the backend - this might be pretty much everything, also depending on the functionality - how much other systems it should integrate with, how many users, what is the hardware infrastructure required, whether some cloud approach (google appengine, amazon) are considered etc. etc.
I work at a company with a large SAP investment, and we also have dozens of large .Net systems (mostly internally for engineering systems), and Java platforms (mostly for external web applications). As such, we have large development shops on ABAP, C#, and Java EE.
We have decent standards for which platform to use in which domain, but we don't have a lot of clarity around when to use web UIs and when to use desktop UIs.
I've seen some excellent research on this topic in the past (like this), but I'd like something a little more structured
I'd like to build a decision tree based on best practices to help with this question.
Some of the criteria I've seen in the past include:
Is the application targeted to users
with different OS configurations?
Does the application require OS-type
functionality for sorting and editing
data? (I know that AJAX /
asynchronous JS has made possible
much richer desktop-like
functionality to web applications,
but some would argue the desktop is
still king in this area)
Will a web application be able to
provide the availability,
responsiveness, clarity, and utility
that can be delivered with a desktop
application?
I think we are seeing the separation between Web and desktop applications softened quite a bit. Rich internet applications (with Flex, Silverlight, Ajax) started this trend, and WPF with XBAP is taking the user experience of browser-based applications to another level.
It is becoming a bit more involved to have this argument, because there are now more flavors in the spectrum between Web and desktop apps.
Some more questions to ask:
What is the primary objective of the app - data manipulation, or data viewing?
What is the number of data points/records that need to be viewed/edited together on one screen?
What is the organization's IT infrastructure look like? Will they be able to accomodate new deployment models?
Will users work with a central database from remote locations?
Does the organization have a VPN infrastructure of off-site users, and how do users authenticate?
Are there existing applications that the same user group is working with, and how are these applications deployed?
Does the application need offline capabilities?
Given that they are so different, what is the skill set of the development team for web and desktop APIs?