I'm using Geonames.org for textbox auto-complete. Very neat feature.
They provide both the database and a REST endpoint, something like this: http://api.geonames.org/postalCodeLookupJSON?postalcode=6600&country=AT&username=demo
However, as per the requirement (decrease auto-complete latency, eliminate external resource dependency) I wish to host the database on my server. Geonames provides the database for export, which is nice. However, then I'm facing a task of writing my own REST service solution for accessing my database with imported geo data.
At the same time, I don't think I'm the only person facing an issue like this, so I was wondering what your takes on this are? What's the fastest, the best solution would be in this situation? Is it really necessary to write a REST service from scratch? Or is there a library for that, and I just can't find it?
Environment: ASP.NET (but it's probably going to be a separate web-application anyways, so I'm open to other offerings such as Node.js, Ruby on Rails - whatever will be the least development time).
Related
I have a single page app built with emberjs with an a rails backend. Is it a common pattern to build an admin interface on rails serverside on a subdomain. What is the right approach for this?
Your question is vague but I will try to answer it my best. I have done this with a Node and a Go backend combined with Ember.js.
No, there is technically nothing to prevent you from doing a single page application for an admin interface.
Rails is a good choice for this, and generally you should stick with the backend framework/language you and your team master the most.
As for what would be the right approach, there is no magic recipes. Document your code, write test and follow best practices for the tools you are using.
One key element though will be the communication between your frontend and your backend. Ember chose to follow the JSON API specification (http://jsonapi.org/) and comes out of the box with an adapter to talk with these kind of API. Using such adapter will help you save a lot of time.
Here are some implementation of JSON API for Ruby : http://jsonapi.org/implementations/#server-libraries-ruby
One more thing about your frontend code structure. You haven't say how big your app will be. If it gets big, you may want to take the pod approach in ember-cli (http://ember-cli.com/user-guide/#pod-structure). It basically changes the structure of the code so it's easier to maintain a lot of files.
I am working on creating a dashboard which would access Redmine project data. This dashboard will be a consolidation of project data (delivery date, manager, start date, total issues, open issues, closed issues, bug count etc.) for all projects in the Redmine database.
Any ideas on how to do this? An SQL query to achieve this would be a good start. I have Redmine setup on my local system and can access the Redmine database.
I plan on creating an HTML5 .Net based web application. Once I figure out the queries to be used, I would write an IIS (or REST) service to fetch the desired data from the Redmine production database.
Any help/pointers would be deeply appreciated.
Regards,
Pranjal
You have basically three options:
use the REST API
develop a redmine plug-in
do some custom SQL stuff
REST API
The best you could do is to use the redmine REST API. Using it, you can fetch the data directly from redmine without any SQL queries or manipulating the server. It should even work when the redmine server is updated.
Redmine Plug-in
The next best thing is probably to develop a redmine plug-in. Your plug-in can access redmine classes (Project, User, etc.). For example, you could do something like Projects.all.map {|p| [p.id, p.identifier]} to get the id and identifier of all projects in an array. This approach is way more powerful than using the REST API, but you have to modify the redmine server (install and maintain your plug-in). A plug-in is probably more fragile when redmine changes internal structures, than the REST API.
Custom SQL stuff
I do not recommend developing custom SQL solutions, but it is an option. Such a solution is harder to develop, more fragile, harder to set up, but might offer better performance.
You can see the the redmine database structure listed in db/schema.rb. Having the right schema, you could develop your custom SQL queries and return them to your dashboard.
Think about security
Apart from the usual security stuff (which you should consider too :)), remember that redmine has a rich permission system. Consider which object you make (publicly) available. This is most important for the last two options. When using the plug-in approach, you should have a look at the User#allowed_to method.
With the little information I have about your requirements, I have the feeling that you should go for the REST API.
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.
I'm writing Django application (social network) and thinking about dividing monolithic project to two projects: UI and API. For example, Django will be used only to render pages, interacting with and taking data from API, written on web.py.
Pros are following:
I can develop and test API independently.
In the future, other UI can appears (mobile, for example), it will require service.
I plan to outsource web UI developing, so, if my application will have two modules, I can provide outside only UI one, not sharing logic of application.
Cons are following:
I'm working alone, and developing two projects are harder, then one.
I will not be able to use cool Django admin panel. I will need to write my own.
web.py is more low-level comparing with Django.
It's like a brain dump, but I will be really appreciated if you share your experience in creating web application with UI module and independent API module.
Update (more specific question, as Mike asked)
What Python framework will you use for creating REST API of social network, which can be used by different client applications? Is using web.py that returns JSON only and rendering it by Django for web is good idea?
Thanks,
Boris.
I've been in a situation similar to yours. I ended up writing both, the UI and the API part in Django. Currently, I am serving them both out of the same process/project. You mentioned you wanted to be able to outsource the UI development, but do hear me out.
In the meantime, I have used django-piston to implement the RESTful front end, but a bit of preparation went into it:
Encapsulate all DB and ORM accesses into a library. You can do that either for your entire project, or on an app by app basis. The library is not just a low-level wrapper around your DB accesses, but also can be for higher-level 'questions', such as "all_comments_posted_by_friends()" or something. This accomplishes two things:
You can call your pre-canned queries from UI views as well as API views without having to re-implement them in multiple places.
You will later be able to replace some - if not all - of the underlying DB logic if you ever feel like going to a NoSQL database, for example, to some other distributed storage model. You can setup your entire app of this ahead of time, without actually having to worry about the complicated details of this right at the start.
The authentication layer for the API was able to accept an HMAC/token based header for programmatic access and normal Django auth. I setup the views in such a way that they would render plain JSON for the programmatic clients (based on content-type), and would render the data structure in HTML (with clickable links and clickable docstrings) if browsed by a human from a browser. This makes it possible that the API is fully explorable and clickable by a human without having to read any docs, while at the same time it can be easily processed by a client just via JSON.
On effect, the database layer I build serves as the internal API. This same database layer can be used from multiple applications, multiple processes, if you wish to do so. The UI views and the REST views were both implemented in Django. They can either be in the same process or in separate processes (as long as they have access to the same database right now).
I plan to make an online game. It will be a full real-time during play. For my website backend I have used Django. Database and other things are almost done. What is the best way to make user client side and server side backend for play in realtime? As I use Django it would be nice to have it in Python.
We plan that there will be minimum ~1000 online players all the time.
Twisted/Tornado/Node.js or maybe something else?
Thanks in advance.
Tornado is very light and pretty nice in my opinion. You could integrate it with Django in various ways -- e.g. Integrate Tornado in Django, Integrating Django with Tornado's web server -- or just run it alongside Django behind whatever web server you use.
Node is so fun that you might tire of Django. :-)
I think you should keep separately Django - which is used for general site functions, and Tornado - which is used for realtime data. I think you should use some Redis to store/read data and communicate between django and tornado, so prevent using database access directly from tornado.
Developing your own backend server sounds as interesting project.
But from my experience it becomes a very significant of your R&D effort.
It starts with developing core backend components, dealing with servers, installs, patches, security issues and more.
On top of it, you will need to create admin systems to manage your player, levels, xp, integration to stores and more... and then, you have the reports (installs, retention, etc'...)
I would strongly recommend using existing backend platforms.