I'm developing an application that consists of a 'fat' javascript client backed by a JSON/REST server for data access. The data is stored in mongodb but the system should be flexible enough to switch to a relational backend if required.
I started out with pintura as the server side framework but recently ran into some problems (specifically with the perstore/filestore). I noticed that one problem has even been reported (including a fix) over a month ago, but there has been no reply to it and the issue is still present.
There seems to be relatively low activity in this project so I was wondering if many people are actually using it, and how stable the framework is.
Does anybody here have experience with this framework or know of an alternative framework that has similar capabilities?
I agree the project and the website/blog does not seem to be active, although the perstore repository does have recent activity. I'd contact the author there since your problem seems more related to that.
A search for REST on http://search.npmjs.org/ will show quite a few results, although I cannot recommend any from experience.
Related
I'm studying Couchdb right now. It looks like I could use Couchdb as a backend and web server without needing anything else. Am I correct? Do people use Couchdb as a only backend? Are there any disadvantages doing so?
The core team seems to have pulled back from this in recent versions, but a few years ago there was a lot more of a push to run standalone apps straight out of the CouchDB, these standalone apps are called "Couch Apps".
I don't know it was ever really more than a proof-of-concept (ie. I don't know that any significant web app is actually running on this platform), but if you're interested, apparently the tools do all still work, and there's still the http://couchapp.org/ site with a lot of good information.
Update
I want to add that if the problem you're trying to solve is the problem of javascript origin security, then you should know that recent CouchDB supports CORS
I'm developing an iOS social networking application that will involve users sharing and rating photos. I've spent about the last year or so on and off teaching myself how to develop in cocoa touch and now I'm ready to get started with the networking aspect of the app. Unfortunately, I have 0 networking / database experience and was wondering if anyone had any good advice on what things to consider and where / how to get started. In all likelihood I'm probably not going to build my own server and instead will go with something like rack space. Any advice would be appreciated.
Getting started to iOS Networking application. Here are the required things:-
You really need good backend developing experience in MySQL and complex database queries Plus experience in developing web services. At the root you need server host for backend and Admin module as you mentioned in question like race space or any other. You need to spend some months with mysql backend,web service and admin module implementation.
For fully functional social networking app your first task will be to manage users. Log in/Sign up will be there. Every user can post his status and can comment to other user's status.All status posts or comments will have their unique id and relationships to userid's table. May be image uploading and comments on photo will also be there So there will be lots of tables and relationships between them on backend side.
For Social Networking app, amount of work will be bigger on both backend/web service side and iOS side.
This is a pretty abstract question.
Eventually, you're going to have to focus on a particular architecture ( which database, which network technology), but before you do that, you need to get an outline idea of what the available options are and what the strengths and weaknesses of each are.
The server database is probably the easiest, as it doesn't make such a big difference. The choices are an sql database ( mysql, sqllite ....), not an sql database ( nosql, in memory tables) or some higher level abstraction where you can hide the differences and decide later ( core data for example). This may be constrained by your deployment decisions, you'll have more choices of rack options if you go for LAMP (Linux, Apache, MySql, PHP) for example. If you stick with apple kit and use a MacOS X back end, you may have additional options for network architecture ( DistributedObjects for instance.
The network architecture is also a difficult choice from a wide range of choices. There are really dozens of options with lots of different pros and cons. As this is your first foray into this area, I'd count ease of use and availability of help high among your priorities. Here are a few popular technologies you might want to investigate ( in alphabetical order to minimise flammability :) ). DistributedObjects ( apple), JAXP, JSON, RPC, SOAP, XML ( bare, without the soapy bits).
One more question you should ask yourself is "Can you get away with just a database connection, or do you need to do processing on the back end?". If you can, you might be able to get away with just using a remote database and then you only need to learn core data ( which will still keep you busy for a long time).
Once you've decided what technologies you want to use, then you can start learning.
You mentioned using a hosted server. You'll want to be able to run a test server locally. Fortunately almost all the worthwhile options for both database and network technology will run on any unix-like machine, so you can probably use your regular dev machine.
Also bear in mind that some of these choices are religious, so everyone you read will have strong biases ( myself definitely included).
Idea: Create an database that I can integrate with an iPhone app.
As I have never worked very in-depth with online databases, I need advice on what methods are best for creating a database. The database would need to contain a list of usernames and passwords to login.
P.S. - I have my own website server.
The easiest thing would be to just use MySQL probably. Then you would define web services that expose basic access to the entities in the database. Best to do those with REST. That might be more than you are up for.
The problem with lesser solutions is that you can't have users just connecting directly to a db from the mobile app. So you have to have something talking to the db.
The other option would be to try to implement the whole thing using Game Center, since that has support for players and scores, etc. Not sure if that would be sufficient. I have looked at it but not in a lot of depth and there are changes coming in iOS 5.
In my opinion there is no need to bother with the iPhone app, just make a mobile version of the website. At the end of the day, you'll have to write the website infrastructure anyway, and with a website there is no need to worry about distribution. You'll even be able to support those using other devices.
If you are still looking for ideas, I learned a lot of what I know of web-based databases from a book called Head First PHP & MySQL (ISBN 978-0-596-00630-3). I already knew SQL and C++ (C++ is similar in many ways to PHP), but you really don't need it with book. It will teach you the very basics of both languages and how to tie them together. It will also give you a good frame of reference to Google solutions or ask informed questions.
Does anyone know what tumblr is written in? I have been trying to figure it out.
It's PHP...
http://www.marco.org/55384019
spiteshow:
I wonder if the Tumblr guys are using a framework or if it is all home brew.
Both: it’s a homebrew framework to add MVC structure and a useful secondary function library to PHP 5 that we started in 2006 and have constantly evolved into a very finely tuned framework for our needs. The same framework runs some of Davidville’s former consulting-client sites as well as all of my personal sites and projects. It’s not available publicly anywhere, but we may release it in the future.
The lead developer's blog features a lot of PHP-related material, and Tumblr was advertising for PHP developers a while ago. This isn't strong evidence, but it's possibly indicative and it's the best I could find.
Here's the full stack as of 2013.
"We're a LAMP based stack (Linux Apache MySQL PHP) with Scala for our many services. Other pieces of tech we use currently in production are Memcached, Varnish and Redis."
http://smcdermott.tumblr.com/post/46847264498/what-language-is-tumblr-written-in-all-php
I just logged in to my account and added the index.php and it worked, so it must be php.
http://www.tumblr.com/dashboard/index.php
For a new J2EE Facebook Connect project, do you recommend:
restfb (http://www.restfb.com), or:
Facebook Java API
(http://code.google.com/p/facebook-java-api)
The requirements cover pretty much everything supported by Facebook Connect.
Completeness, ease of use, stability, etc are important. But what matters the most to us are the odds that the selected library flourishes and ends up being the winner, if there is such at thing.
Thank you.
With the new OAuth2 based authorization flow and the Graph API, the amount of "work" an SDK does has been greatly reduced. I'd suggest that you choose a library that does not try to provide very high level abstractions, and instead understand and leverage the fact that you're making HTTP API calls (for instance, for parallelization of HTTP requests). We recently released an Android SDK which while not related to your question, may be a good point of reference.
For full disclosure, I mavenized RestFB and have commit rights to the project. That said, I was in the same position some time ago, needing some Java library for working with FB's Graph API. Originally, I tried out facebook-java-api, but it didn't support all the newer APIs. I peaked into the code at the time and saw some inherent inflexibility that made it overly complicated to do what I needed so I looked around for alternatives. In all fairness to facebook-java-api, perhaps I just caught them at a bad time (around 6 months ago, there were only minor updates to 2.x and no 3.x in sight at the time. I see they've released 3.0.2 recently).
Anyhow, I then found RestFB. What I liked about it from the very beginning was how clean and extensible the code was and that it didn't require any extra dependencies. The basic Graph API objects are built-in and it's very simple to create new ones. There were one or two minor things that didn't work out of the box, so I opened issues and Mark Allen, the founder of the RestFB project, seemed pretty responsive with fixing them so I stuck to using it. More recently, I contributed Maven build to the project since I was keen on seeing the RestFB libs on Maven Central to make it easier for myself to use them.