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.
Related
I am using an PHP MVC framework (Yii, but my question could apply to most MVC frameworks) to create a project that should include a web application (website) and RESTful web service. I am facing an early design decision on how to logically separate the application and service logic. Here are some true facts:
The web app and web service will share a lot of functionality and only differ in rendered format (View vs JSON)...
...But, the web app and web service will have some unique features (ie, there will be things that the web app does that the service does not, and vice-versa)
Here are my desires:
I would like to share the common functionality's implementation as much as possible
I do not want the Controller to become unwieldy as a result of combining web service/web application logic
I have a a slight distaste for creating separate web service and web app controllers, especially when they overlap in Actions (other than the rendered format)
I do not want to have the web site consume the web service unless it is really a necessary design decision; I will lose out on a lot of built-in features that use database interfaces and/or have to create classes that conform to available IDataSource and other such interfaces by hooking it up to the web service; also there could be a slight performance decline.
I have thought about it a bit and come up with some solutions below. Please let me know which of these you think would meet my wants or let me know if my wants are not reasonable/counter-productive.
Implement completely separate controllers for WebApp and WebService (modularize the two so that they share no code)
Implement separate controllers for WebApp and WebService, but create methods that do the heavy lifting and call those methods to share implementation - for example, if I wanted to do a item/findBySomeCrazyCriteria I would route to the appropriate controller depending on the URL, but each controller would reference some FindItemsBySomeCrazyCriteriaFunction() defined elsewhere.
Make the web app consume the web service (which would require me to expand the planned functionality of the service)
Implement one controller for both WebApp and WebService, which extends from a BaseController that includes generic hooks for REST type stuff in terms of $this->getModel()` and use overrides where necessary
Anything else
Although my question is related to Yii, I feel like this must have come up in the past for many developers. I would like to know what you did/what you recommend to move forward. I am concerned that if I choose the wrong approach I will "break MVC" or somehow regret it later.
Note: you should not worry about "breaking the MVC". Since you have chosen to use Yii, that part has already happened.
The root of the problem lays in the fact that your controllers do a lot of stuff (and thus, violating SRP). What you call "controllers' actually contain also the application logic (that should be part of model layer) and UI logic (that normally would be part of view instances).
What you should have there is a single application, with one model layer and two presentations (what you refer to as "web application" and "web service"). The controllers should be a slight a possible.
You should move the application logic to the service layer through which then the presentation layer would interact with model. You would end up with a lot lighter controller. Then you could be able to provide a separate set of controllers/view for each of the presentations that your project needs with no or minor code duplication.
I would recommend against writing multiple controllers. It is a much better option to keep your domain logic in the models, rather than controllers. Your controllers should only act as the gateway to the logic and serve them in whatever form the client requests eg. as a JSON encoded response or through a view. It would be best if you just keep the task of identifying the client requirements and after obtaining the results from the model translating the response in an appropriate form.
This flow can be streamlined with suitable helpers and a well implemented routing sub-system so that detection of client requirements becomes effortless.
eg. /user/subscriptions.html will fetch an html page where as /user/subscriptions.json will fetch a JSON response.
I'm currently developing a web application, that relies heavily on mobile and desktop clients consulting the web server for information. This can be accomplished nicely making a RESTful API available to handle this. So my idea is to have an application acting as the "platform" which handles all the real business logic and database information behind the curtains.
My plan is to make the platform using symfony2 and OAuth 2.0 authentication mechanisms, combined with RESTful web services.
Now my real dilema comes on the website component. Ideally I would like to think of the website as yet another client that asks this REST platform for information, and completely separate it from the platform itself.
To make it a little bit more clear, let's say we are making a blog with this architecture, so one would have a "platform/backend" that provides a rest service to list articles, for example: /articles/5. This on the backend, and with symfony2/doctrine means that the app has an Article model class, and these can be requested from the DB. A simple controller queries for the Article number 5 and returns all the information in JSON format.
Now the website on this example, could just do the easy thing and also have an Article entity and just query the database directly, but I think it would be cleaner if it could just talk to the platform through it's REST api and use that information as a "backend" for the entities.
So the real question would be, is there anyway to support this kind of design using symfony2? Have entities rely on a REST api for CRUD operations? Or I'm just better off making the platform/website a single thing and share a "CoreBundle" with all the generic entities?
There is nothing in Symfony that prevents you from doing you want.
On the client side you could use Backbone.js or Spine.js.
Have a look at FosRestBundle, it makes your life much easier to create api:
https://github.com/FriendsOfSymfony/FOSRestBundle/blob/master/Resources/doc/index.md
I am in the process of designing an application that users will be able to log on remotely and use - via a web interface.
Security is of paramount importance (think credit card and personal banking type information)- so I need to make sure that I get the security aspect nailed down - HARD.
I intend to provide the application functionality via traditional (stateful) web pages , as well as web services.
For what its worth, I am intending to use web2py as my web application framework.
Is there a list of guidelines I can follow to make sure that I have all areas covered?
One stop shopping: https://www.owasp.org/index.php/Main_Page
Read that and take every suggestion to heart.
you should consider at least the following:
authentication. getting users to log on in some manner. which authentication method they use depends on what you aim to provide
privacy. making sure the information they send is only visible to them and your application and not an eavesdropper.
in the simplest case SSL can take care of both of the above. it will always provide encryption but can also be used to authenticate or at least make some simple authentication mechanism more secure. one thing to look at is security of ssl. ssl is suceptible to a man in the middle attack particluarly when the users already have a trust relationship with, say, their employer - who can them proceed to install an ssl gateway which is effectively a mim.
authorisation. making sure users are only allowed to see what you want them to see and no more.
this really depends on technology you are using.
non reputidation. making sure the user cannot dispute the actions they perform
this is a very open ended question. legally this is seldom (never?) used so it depends... something like signed logs of user requested actions for example is probably enough.
Your biggest threat, by far, is writing server-side webapp code that introduces vulnerabilities in your web application layer. This is not something you can checklist. For a starter, make sure you are 100% comfortable with the items in the OWASP Top Ten and understand how to code safely against them. If you are not expert in web application vulnerabilities, strongly consider hiring someone who is to help review the web layer. At the least, i would consider contacting a security testing company to perform some form of penetration testing, preferably with a code review component.
If you ever do anything with credit card data, you will need to comply with the PCI DSS which will require at least quarterly remote-testing from an Approved Scanning Vendor.
I have a fairly conventional Grails application. It's monolithic; although it's somewhat split into plugins along functionality lines, it is built into a single war for deployment. Due to company architectural constraints, I need to consider isolating the app's persistence into a web service (or series of web services). What's the best approach to dividing a Grails application into a persistence service and a presentation application?
Put your domain classes in a Grails plugin, and have two distinct Grails applications, one for your web front-end and one for your web service. Both access the database directly, but code for persistence is not duplicated.
Here is a blog post that have some more details on how to realize that.
I don't have an out-of-the-box solution for your problem, and I don't believe there is one. I'll just explain the solution I use and what I would consider in your case.
In my organisation, our approach is to separate our applications in a Grails back-end and a front-end in Flex. The reason is that we have many ready-to-use Flex components that would take too much time to re-implement using pure web technologies, but here's not my point.
Creating a REST back-end in Grails is quick, as views are scaffolded when appropriate, controllers are straightforward, and input validation is greatly simplified by Domain constraints.
The drawback of this split is that definition of domain objects have to be duplicated in the front-end. You might includes objects validation in the front-end or not, but if you omit them, it will have an influence on UI responsiveness (requests to the REST back-end in AJAX calls for real-time validation to get the errors). At the end, our application is quite cumbersome because modifying objects in the back-end implies modification in the front-end. Furthermore, we do validation in both the front-end AND the back-end, and this code is not shared, so it must stay in phase and maintained at two places.
Our applications are split in a way that's similar to two completely distinct Grails applications that would share no code. A solution that would work in your case but is not what you are looking for, for sure.
In your case, I see two viable solutions for the web front-end:
use the Groovy REST client library to fetch and send back your domain objects directly from your controller. If needed, pack them in command objects that reflect your domain objects, so that you can share validation code with the back-end.
create some kind of REST GORM that replaces Hibernate with queries to your REST web service. You could look at the GORM for Mongo Plugin as an example of how to create such a GORM replacement.
I like the last idea, it would be a useful public plug-in. It doesn't exist yet, unfortunetly.
We'll be developing mobile applications (for both iOS and Android platforms) that will be using web services. I'll be the one implementing the web services part and I plan on using Apache CXF.
It would be the first time I'm using CXF but I'm highly considering it because of its integration with Spring.
What are the potential issues (if any) with using CXF for mobile apps? If there are, is there supposed to be a better alternative to CXF? If there are none, any best practices I should also be considering?
Thanks!
I've been through the mobile ringer... WAP, J2ME, Brew, embedded languages, etc. Mobile development is exciting and also a bit scary...
Spring Integration: There is a big difference between * and **... be careful when setting up filters. It's easy to get out of hand securing end-points.
Authentication: How will your mobile devices authenticate and what is their role in Authentication, Authorization, and Access? Session management on occasionally connected devices - can get interesting. If a session goes stale how are you going to handle challenge / response?
App Security: Does your solution require SSL? Managing self-signed certificates is painful and time consuming. Do yourself and your mobile devs a favor and get a CA certificate in place up-front. You will save time (money) and a great deal of headache.
Proxy Power: Ideally, the people writing the front-end should be using an IDE that supports some kind of tethering for realtime debugging. Being able to add a breakpoint and introspect what's going on in the code... is mint. However, I haven't seen an IDE yet that gives front-end mobile devs the same experience as back-end devs. My guess is that your mobile devs are going all goo-goo eyes over jQuery. Understandably so! WebStorm and Aptana are good in the JS arena - but they're still evolving.
This is a problem front-end mobile devs need to work out... right? Yes... and no. Without proper tools everyone in the dev-chain will have to cook-up their own ways of answering questions like:
What did the mobile app send?
Was the request formed correctly?
What was the response?
Again, save yourself some time and finger-pointing and just sit down together (front and back-end devs) and work out a tech-stack that provides everyone optimal access to all app communications. Configurable logging on the server is a good idea to have in place from inception. Are you familiar with Firebug or Charles Proxy? A proxy can greatly simplify the debugging equation - just sayin'
Exceptions: Oh... and beware HTTP response codes. Exceptions on the server-side should be gracefully handled to prevent mobile consumers from choking on responses. Yikes - that's all I can say is YIKES!
Service / Life Cycle: Have you calculated the duration of the service and / or life cycle of your application? Knowing this can greatly impact architectural decisions.
Web Services: My knee-jerk reaction - is this the best technology for your product? Why Web Services? Can you come up with three concrete reasons why WS is the best option? From my experience, the most compact protocol will usually lead to the best user experience.
Food for thought... ASP.NET and JSon make a good pair.
http://encosia.com/using-jquery-to-consume-aspnet-json-web-services/
SOAP-XML is cumbersome. :-(
http://openlandscape.net/2009/09/25/call-soap-xm-web-services-with-jquery-ajax/
Have you considered RESTful Web Services? If you're using CXF... there are three different ways to build RESTful Web Services.
JAX-RS (CXF has an implementation of JSR-311 baked-in)
JAX-WS (more complicated - meh)
HTTP Binding (deprecated... may be removed from CXF in the future - fair warning)
More at: http://cxf.apache.org/docs/restful-services.html
Examples: http://solutionsfit.com/blog/2010/04/21/enterprise-mashups-with-restful-web-services-and-jquery-part-1/
Alternatives: There are so many great projects out there... Axis2 and Shiro come to mind. Without knowing more about your solution - it's difficult to recommend anything.
Final Thoughts: As a back-end dev, I would recommend getting familiar with the entire app tech stack and kick-off development with a series of small but functional samples that light the way through the obstacles mentioned above. Hold-on to the samples! They may prove useful in zeroing in on regression.
Mobile devices are getting faster and faster every day... it's true, but any dev worth their salt will know that they need to code to a common denominator if they want a mobile product to be widely consumed, adopted, and embraced.