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.
Related
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.
We're about to start a new project and I've been looking at some of the new web technologies. We want to build a RESTful api which a client can access. To date we've been using python with django/flask to build the api and using jquery for the front end.
I've read quite a bit on javascript frameworks such as emberjs and angular, as well as nodejs solutions like express, meteor and derby. I really like the idea that a site should 'auto update' when the model changes.I'm aware that there are some libraries like gevent which can help facilitate socket level communication, but it seems to be more of a patch than an elegant solution.
Ideally, I don't want to give up a proven technology, ie writing server code in python (or php,ruby whatever) for building my whole app on nodejs. Having a RESTful API is important since we want our services to be open and accessible.
Would it be a bad idea to have 2 servers and 1 client? 1 traditional api server communicating with a javascript framework on the client. Then also run a nodejs server alongside the api server which can somehow talk to the api and if it finds updates, passes it along to the client.
We want to build a RESTful api which a client can access.
Ideally, I don't want to give up a proven technology, ie writing server code in python (or php,ruby whatever) for building my whole app on nodejs.
Then you should probably go with Rails and Ember.js. I'll quote eviltrout (co-founder of discourse) which is build on ember and rails:
One amazing side effect of a rich client side app is you end up with a battle tested API. Our app has consumed our own API since day one, so we know it works.
If we want to create a native client for Android or iOS, it would be a lot easier because we already speak JSON fluently. If people want to build services that use Discourse, they won’t have to result to screen scraping. It’s a huge win for us and the developers that use our platform. 1
However you should keep in mind that ember is as of to date still a very young framework (rc3 v1.0.0).
I don't know what sort of application you are building (in respect to why you would want to use node) How to decide when to use Node.js?
What is difference between a Desktop application and a Web development application? What is Testing Strategy for a web site/web application?
I will briefly share some of my experiences, as they may help establish a foundation for you.
The main differences that I have encountered are obviously the usage of markup languages (HTML/HTML5/XML, etc), AJAX, jQuery, and javascript (well, scripting in general). Tools like .NET framework amongst others also exist. You can look those up to get a full definition of what they are and how they work together, but they introduce a new way of problem solving in terms of building small bridges to reach the end result.
As in any application, keep in mind the user-end side of the application. Millions of people will have access to it at exactly the same time. Security is paramount with web apps. Ensure you have strong security measures tied into your page.
Aesthetics will take more precedence than with desk applications (depending on what they are). Web applications are a visual experience. You want to make sure that when you design it, fields are easily identifiable, the app is easy navigable, and easy to read.
For testing, simply save your code with the right extension and run it from wherever you saved it. Most current Op Systems know what kind of web code the file is written in and will open it in a browser. Say if you wrote "myPage.html" and saved it to your desktop, you will see an HTML icon that says "myPage". If you need to make changes, edit your code, re-save it, then simply refresh your web browser.
I know this is a very very general answer but I'm attempting to brush upon everything that I've experienced over the summer. Hopefully this is helpful, or atleast brings some considerations to mind when designing your web app. Good luck!
This is not a question about writing a web-app Vs a desktop app. It's a question about allowing a bespoke application to run in a browser though use of a custom plugin, effectively using the browser just as your render-window.
QuakeLive does this - it's a C++ application with some extra code to run through a browser. Unity3D and Torque game engines also provide deployment options to do the same thing.
Personally, I'm a bit dubious about the usefulness of such a system. But I'd welcome other opinions on the reasons why this might or might not be a good idea.
Not sure if there's a proper term for this, please edit my tags if there is!
It depends on the application. My background is in medical imaging, but what I have to say would apply to many information system clients:
Pros:
it gets easier to build REST-based integrations between applications. This type of integrations can be used by admins to build integrated portals. (So case ID's from one application can be used to launch another with the right context etc).
ideally, users can install your application themselves, on-demand (depends on context if this is really possible)
Deployment of new versions gets easier. Usually the hosting technology has deployment built-in. In client server environments, this can save a lot of work for the IT department.
You can have a single start URL for PC's and thin web clients (like phones). This makes it easy for users to find your application.
You can centralize configuration for clients. For standalone clients, you could of course centralize configuration somehow, but if you app is web based, you always know for sure there is a server, so you can always use it.
you can offload work that's ineficcient to do locally to the server. (reduce # of roundtrips between client/server).
Cons:
Each browser vendor has its own model of wrapping the native code. There are not too many, but it's definetly extra work.
Your app has to "play nice" with the hosting application. Like when the user closes the browser window, the browser may have prescribed when and how you can ask the user to save.
updates to browsers can break your plugin.
system admins may have restricted installation of plugins, disallowing users to install your application on demand (this happens a lot for activex).
your users may not like that extra code is injected into the browser (there is a lot of malware around that does this)
you don't have the opportunity to update prerequisites before installation
I don't believe really that it's just wrapping existing code in a plugin framework.
Your application won't work anymore when the server is down...
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?