I'm programming a mobile application in Sencha Touch with the backend being Rails. I've found that I've been separating the two more and more as I get deeper into Sencha: where Im basically at the point where Rails only functions as my model storage (database) and Sencha pulls in everything it needs via JSON - reproducing much of the logic already present in rails.
My question, is what do you advise when it comes to delegating functions to each application? I've implemented REST in my Sencha app so it can communicate User, and associated data and store it in the same format.
Is this the right way to go for User Session management? Should I give more power back to rails? IE : where do I store the session? Can I do it on the server? Should I do it as session storage management? Local storage? I just dont know.
I'd appreciate any advice. Thanks.
This is not exactly a specific answer to your question, but I would just like to add that I do think you're on the right lines, and I wouldn't be worried that you've overstepped the architectural line, so to speak.
The web is going from one of rendered documents (where the server did absolutely everything and the browser was essentially dumb) to one where the browser and server are more symmetric peers - and your challenges become more around keeping two fully-fledged MVC apps in sync!
(Arguably, we might see a world where servers become fairly dumb, relative to the richness of the applications on the client side. I guess this is just the next cycle of the thick-client/thin-client pendulum that's been swinging for decades ;-) )
But for mobile, this is not just some arbitrary computer science problem - the mobile device might easily have partial or sporadic network coverage, and so the ultimate test of your application design is to work out whether the user can continue to work on the app when the device is offline - driven into a tunnel, for example - and then re-sync back once the network is available again. A rich, responsive client is really the only way to go.
In that scenario, storing the session richly in the browser seems like a reasonable step. In fact, it's easier to keep session state in sync between a single client and a server than it might for some other types of data record (that might be being manipulated by multiple clients simultaneously).
Related
I want to develop a native application to ios.
I want to build an app that is a mix of Instagram and YouTube,generally.
I need to persist and get data to and from the database,store user data(images,videos,audio etc.), Allow user to edit his uploaded media ( images,videos,audio etc.).Also things such as drag and drop, GPS and image edition are added.
So far I think these are the most demanding features that app will contain.
I think about using swift for the front end, but I am still considering what language and database to go with to develop this application.
I though I should maybe go with php laravel framework RESTful api(since I know it already), combined with firebase.
Any better suggestion you might think about, and why?
Will appreciate your honest thoughts about this.
I was really putting the last hours in order to determine the right language for developing the back-end and the database. And I reckon that really node.js and mongoDB , along with Swift will make the perfect match!
node.js seems to be good for my app, as it does not really require very complex computing, and MongoDB is ideal for social networking features. These are the main reasons I am going with this stack :)
Also,about scalability, it's easier in MongoDB,rather than MySQL.
I’m working on an iOS app that aggregates contents (i.e. events) from different services (Google Calendar, Basecamp…) using their REST APIs.
Instead of querying these services in the client, I wonder if it wouldn’t make more sense to do it server side. This would allow me to unify the different models beforehand, reduce the client side logic significantly, and IMO make it both more scalable and easier to maintain.
But I have no experience of this kind of backend and no idea where to start, or even if it’s a good idea at all? Do you have any idea? I was thinking of using Node.js and Express/LoopBack…
Thank you in advance for your help!
David
I am afraid this question will be soon marked as opinionated, and myself most likely be down voted... but maybe I will be on time to pass a little of my experience working on a back-end for my employer.
If you do not need to impose any control over who and when and what data is being pulled from those multiple external services it makes more sense to free yourself from the hurdle of developing and maintaining your own back end. Keep in mind the costs associated with having to support your own servers...
Additionally, having this logic on the client scales proportionate to the external services being used while with your own back end you will have to make sure that it is programmed to scale well, which could be a considerable undertaking if you never did it (not saying that it is impossible to learn in a reasonable timeframe).
Basically, what I am saying is it is always better to delegate security/control agnostic logic to the client side. This way by the way, you will be following along the lines of currently buzzing micro-services trend :)
I've been reading lately about SPA and how good it is..
I was wondering if someone could tell when should I use or even better when shouldn't I use SPA as go with regular MVC
The tooling for MVC (Rails, MVC4) is much more mature. There is far more documentation focusing on the development of traditional MVC sites. Single Page Application development is HARD. JavaScript-dense applications are difficult to write and can be extremely difficult to debug.
If you want to jump into SPA, look into John Papa's video training series on Pluralsight.com - which, to my knowledge, offers the best starting point for developing SPA apps. Or study Backbone, but that's simply not for the faint (feint?) of heart.
One futher suggestion: if you're a ASP.Net developer, look into BreezeJS (http://www.breezejs.com) for data management.
This blog post gives a good overview of some of the potential issues with SPAs, along with some suggestions for workarounds.
The potential issues include:
Browsers are not the best species in memory handling and garbage collection. Specially when it comes to DOM handling. For example, elements removed from DOM are stil held in memory. If we let users to
work on DOM for a long time without a refresh, Browser might struggle
to cop up with memory issues
We should ideally reuse as much as DOM elements without disposing. But even with that approach, if the user creates thousands of reusable DOM elements as she uses the application, browser may suffer in coping up. On the other hand, the memory leaks created by bad coding practices will too pile up in a long lived DOM.
If we need the complete product suite functionality to be available as a single page application, it can be too much of JS/CSS code to be
loaded at once impacting the initial load time.
I've been reading lately about SPA and how good it is..
SPAs just invert the responsibilities of the browser-client. Traditional server-side applications do most of the work in the backend. SPAs do most of the work on the front-end.
The good thing is, generating views in the client means front-end devs can do all of their design in the browser without having to worry about touching the backend.
Decoupling View from Model (ie controllers exist on both ends) means that the data can be exposed as a REST API on the server and re-used for clients that target other platforms (ex mobile, tablet, smart tv).
Eliminating the need to refresh every time a page is loaded makes for a better user experience.
I was wondering if someone could tell when should I use or even better when shouldn't I use SPA as go with regular MVC
Switching over to building SPAs from server-side MVC architectures can be very challenging for some. Many devs who work exclusive in a server-side language may just hate having to deal with Javascript (esp devs who program exclusively in statically-typed languages).
Making SPA's work requires some url-rewriting and redirect workarounds. This may be a very confusing/harrowing experience to get working for those who don't have a lower-level understanding of the server.
Users that have Javascript off by default will not be able to load the site.
A SPA introduces a lot more load on the client, with everything running in the main context this can make the UI slow/unresponsive. There are workarounds to solve this issue in newer SPA frameworks but it's good to keep it in mind.
Writing code code for the browser is a lot different than writing code for the server. There is a lot more complexity (ex the DOM) in the browser.
The toolchain for front-end development is drastically different from what you'd find being used to develop most server-side languages. Some programmers live-and-die by their IDEs.
Fetching data dynamically via Ajax can be extremely difficult at first for some. Especially, devs who don't have a solid understanding of HTTP.
Really, it comes down to one question. Do you want to take the time to learn how to build SPAs?
This question contains a lot of background information, to make sure you fully understand why we are looking at these technologies.
The question is basically this:
For a large, spreadsheet-type, module that we need to develop for our webmodule for our application, are there any pitfalls we should know about if we decide to use Silverlight for it?
Issues we already know, and don't need any discussion/reminders about:
We're aware of the problems around using a plugin-type solution, which may or may not be installed on the users machine (and in some cases, probably can't be installed). These risks needs to be mitigated, but we're aware of them. Please don't get hung up on this.
We're a .NET company, so while ruby on rails and lots of other different platforms and architectures are good for this solution, they are not in the scope of the decision here. We have lots of code already written in .NET that we need to take advantage of, otherwise the project will never be finished regardless of platform.
Background
We have a web module for our application with employee-related information and some input forms. Our Windows desktop application is mostly a department leader type of application, to manage employees, but the web module contains mostly employee-centric functions. The web module contains mostly report-type webpages, to list information from the system, or input-forms.
The module we need to add now is more of a heavy spreadsheet type application. You change something one place, and something changes somewhere else, like sums, what is enabled/disabled, etc.
We know we can manage all of that with AJAX, but another issue here is that the application will potentially load a lot of database data in order to put the data in front of the user, and with a AJAXy solution, we're afraid that the request/response method here will have to reload quite a lot of information on every request, even to respond to seemingly easy questions.
A way to mitigate that would basically be to load information into a Session-object or similar, but that's a big no-no, so we'd rather not do that. This is a multi-user module, and some of the data is rather static, but some of the data is also going to have to be refreshed from time to time, so if 10 users loads a lot of data into the session, that's going to be a pretty big memory-hit.
We will be using ASP.NET (MVC) for this if we choose to go this route, that is, developing the module in pure HTML and similar technologies.
Then we looked at Silverlight, and would then load all the information down into the Silverlight application on the client. It would hold the current state, and would only need to touch the database to refresh some of the information, some of the time, instead, as we think the request/response model with ASP.NET (MVC) would work, on every little request.
But, since we have only done minor things with Silverlight, we're not that experienced with it, and we're afraid that some assumptions we might have, stated or unconcious, turns out to be wrong or flawed, which will make this project impossible or very hard to manage at some point.
For instance, just to take an example, is there a limit to how much memory the Silverlight application is allowed to load (I know, if I have to ask I can probably not afford it), for instance if there is a limit on 10MB, then that would be nice to know about before we're midway and start to load the really heavy data.
To make it simpler to give examples, let's just assume we're building a spreadsheet, that has so much data, that for the simple "changed a number here, what else changed", too much data from the database has to be loaded for a proper request/response model to be used, and if we move the entire thing to Silverlight, what will make that project hard or impossible?
Knowing about such things would at least give us the ability to consider if the price is acceptable.
In short, why should we not use Silverlight for this and instead go for ASP.NET (MVC)?
And again, "use Ruby on Rails instead", is not really an answer here. The options are ASP.NET (MVC) which we have experience with, or Silverlight which we don't but can gain.
Of course, if Ruby on rails, given that we'd have to start pretty much from scratch infrastructure-wise, and have to learn a new programming language, and framework, and download and learn a new IDE/tool, if it would still allow us to cut the development time in half, then please give us some information about how that might work, but I daresay that won't really happen here.
You should know that Silverlight (version 3.0) does not support any printing whatsoever, which to me sounds like a whopper of a showstopper for you (sorry, I couldn't resist). The good news is that full printing support has been added in version 4, but that is still in beta. Rumours say it should be out before the summer if everything works out according to plan, so if that fits with your roadmap I would use SL4 right from the start.
There are no memory limitations in Silverlight, but for the local storage (IsolatedStorage) mechanism there is a default limit of 1MB. But you can easily get around that by asking the users permission to increase the local storage space when he/she starts up the application. More on that here: Silverlight Tip of the Day #20 – How to Increase your Isolated Storage Quota.
(Edit)
Aside from the missing printing functionality that will be fixed in SL4 I cannot see any problems with your scenario. I would easily take the Silverlight route if I were you, especially since you already have extensive knowledge of .NET/C#.
For a rich interface as you've described, I would definately go with Silverlight or Flash rather than a html/javascript/ajax solution.
These technologies make for much better and consistent interfaces across platforms, you can buy in various components to speed things up and support things like copy-n-paste and code in a more structured way.
Another element is skills, if you have the skills to achieve it in a particular technology, then go with that.
To the answer you question the best way I can; you should not use silverlight if you decide to use flash.
HTH
As the Silverlight team worked through the betas, one glaring pain point that is existing in the realm of Silverlight 3 is the ability to have an offline database, so that you can right-click on the SL application, install it locally, and then be able to manipulate data in a local setting, without the Internet.
I've read a few articles where items such as Google Gears with SQLite had been used, but so far, no one has come up with a decent method by which someone can do the same thing with a SQL CE database.
I'm theorizing, and wanted to gain feedback... So many times, with LOB applications, you have the need for installing a "driver" into your system, which winds up being some sort of data access component or other monitoring device used by the LOB application. What I'm thinking about is to use a ClickOnce strategy and build a driver that would get installed on the local machine, and then make a "local" webservice for when the user is offline.
Has anyone tried this scenario, and if so, what were the pros/cons of the method? If you didn't finalize on this method, then what was your final decision based on experience, and what would you advise going forward for someone trying to crack this nut for their project?
Here's the best I could find for a SQLite-ish experience:
http://silverdb.codeplex.com/
I've been trying for supporting the direct database access in Silverlight since five or six months back. After exploring quite a few different to port the database to Silverlight, we got one POC working with one object database but it's a bit far for us to release it... I may probably write about this in my blog soon.
I dont think that making a "local" webservice is a good idea since the clients may not have any web service installed on their machine.
Thanks to Jeremy Likeness, there seems to be a great open-source project that he developed which may indeed solve most of my problems... just need to figure out how to render reports without a callback to the server, and then I'm golden, when it's time to revive this project (if all goes well, that'll be sometime in 2012)