I'm currently developing an iOS app and have reached the point where I need to implement a server back-end in order to support the core functionality.The app is built in a way to store certain questions locally (Within the app) and pose the questions to the app user. I need to tweak it such that it retrieves the question from a remote server. Furthermore, the question will reside in a specific folder within the remote DB. So the app will have to fetch the questions from the appropriate folder based on user login.
I have zero server experience and am need of some advise as to where I should begin with this. I would like to know if there is a template spec for this kind of task. With a template spec, I can hire a programmer and talk intelligently. Please help!
Here is a number of solutions:
1) You can use other services that provide backend functionality with REST API (as #Niklas Hein mentioned), it calls BAAS - backend as a service, such as Parse (but Parse is closing his service in one year), BaasBox, etc.
2) You can use CloudKit. This is service created by Apple, where you can store app data in the cloud, with authorization, requests, admin panel, etc.
3) Create you own back end. Here is a large number of languages and web frameworks, so php is not the only one solution. Ruby on Rails, Python Django, NodeJS, and many others on your choice.
There are plenty of BAAS (Backend as a service) provider, like Parse or Firebase. You might want to have a look into them. (Although Parse is going to shut down.)
Another simple way is to look into PHP Laravel.
Laravel is a great Framework which makes it really easy to set up a backend.
Have a look at Laracast
Related
I want to create following project :
Server application hosted on Azure - it connects to databse via Entity framework and gives and API for anyone who want to connect (but with account stored in SQL database)
WPF application - it consumes server methods, objects etc.
Web app (php & javascript) - also consumes server methods and object etc.
IMPORTANT : I have only azure student's subscription and I want to hold onto it - buying anything else is out of the question unless it has strong argumentation.
I figured that to do this I have to create REST Web API because I have no other choice to connect to server than via HTTPWebRequest (because I want to have the same API for WPF nad web app).
My question is : does better solution exists?
I think I can create different API's for desktop client than web app but I have no idea how to do that. Whould you be so kindly to show me other way?
Why dont I want to have this solution?
Reason is simple. For big databases and slow internet connection it would take ages to download whole data in few seconds. As far as my knowledge goes there is no lazy loading in REST thus my WPF application's thread reponsible for downloading database would freeze for a big period of time.
If my question is too broad please leave a comment before you put up a flag.
Also, any tips regarding my project design are well appreciated.
Different APIs for Desktop and Web: this can be done easily enough. Assume you have a class library to contain your business logic (domain stuff). Create a web api project that makes use of it, then create yet another web api project separately that also makes use of the core models. When you deploy, deploy each separately to a different domain/subdomain (I'm unsure if you'll require further Azure resources for this, but consider api.desktop.myapp.com and api.web.myapp.com... no real technical reason why you can't do it that way, though for architecture reasons I'd avoid it (it's really coming close to if not definitely is duplication of code).
Same API for Desktop and Web: you stated that you thought you'd have to do this differently for the desktop and web, specifically because of the resource usage on the server. I disagree here, and think you should implement some standardized rate limiting into your API. Typically this is done by allowing only X amount of resources to be returned in a single call. If the initial request asks for more than X limit, an offset/nextID is returned by the API, and the client submits a new request noting that offset/nextID. This means you have subsequent calls from the client to get everything it needs, but gives your server a chance to handle it in smaller chunks (e.g., check for rate limits, throttling, load balancing, etc). See the leaky bucket algorithm for an implementation that I prefer, myself: https://en.wikipedia.org/wiki/Leaky_bucket)
I need to build an iphone app that talks to a website. Logins, fetching data etc.
I have built few apps that does these using website's api but the website I'm working with now does not have one. I don't have enough knowledge of PHP or RoR so I'm not sure if I could build a back-end API from scratch and then start on the ios development.
I did some research and it looked like there are websites like parse.com or appactive where they help you with back-end api. Though, I looked around the website and read the about page but I'm still not sure how they work. Could those services help me if I already have a server/website running and I need an app that requires login and data exchanges?
Jus a note, in 2016 Parse has closed (it's now open source and you run it on Heroku or whatever). There are many other "baas" such as Firebase etc.
Since there seems to be some confusion,
(a) your current service has no API. it is, thus, unfortunately essentially useless so your most absolutely time saving step from here would be just scrap it and use parse (or another baas) as the backend. you can have parse up and running in minutes. what previously took server developers man-years is now just like "a consumer product", just make a few clicks to add column-names
(b) your current service has no API. assuming yo DO WANT TO continue to use it, you will have to somehow add an API, using php or whatever. there's no way to avoid this. IF you do that, then you could (if you wanted) make a "basic" API that parse can get the info from, and then use parse to actually connect to the ios/android builds (since that is so easy)
TBC, here's literally how you do that in Parse,
https://parse.com/docs/cloud_code_guide#networking
"Cloud Code allows sending HTTP requests to any HTTP Server" it's that simple.
As I mention above, it's far easier just to scratch your current backend and change to a bAAs (such as Parse). you have to "go with the times" you know?
Note that the development and testing of an API on a service is incedibly time consuming, it is a huge job for a team.
Here on this question you seem to be asking about bAAs and how they fit in the formula. the answers are:
(1) if you simply scrap your current service, do everything on a baas: it is trivial. what used to take literally man-years is now a few clicks
(2) in terms of "helping you ADD AN API to that service". bAAs cannot help you with that in any way and is irrelevant
(3) if you DO have a service with an API, yes it is relatively easy to have bAAs "link in" to that. (i include literally the doco from pare on doing that above)
Hope it helps!!!
Q: How would you create a SSO? What would you do about authentication (separate app or same as sso) and user store?
Background info:
We have 40+ php apps, java apps and
Ruby apps.
Currently, we have a custom
SSO+authentication solution. It's an
app written in php that is now used as
SSO, while supporting
email/username/phone-number + password
as authentication. It works, but was
built for a few apps only, not
originally meant to be the SSO -
solution. It doesn't have a usable view, every app create their own login/register forms and use the API. They share context and we'd like a more universal design.
Now we know want to support Oauth and
openid solutions, as facebook connect,
google and more, (or do we really?), in addition to
existing authentications. We can
expand existing php-solution, but we
are considering alternatives.
If you were to do all this in Ruby, what would you do?
Some additional info:
All users exist in SSO, today.
The company does aquire other companies/systems at times, having their own users. Would you migrate or create some kind of mapper?
Customers in a Microsoft CRM, but I consider this unrelated. Or do I?
I've shallowly looked at RubyCAS and ClassyCAS, and don't know if they are suitable. Is CAS the way to go?
Would you keep going with php? What would you use?
As you see, I have a lot of questions. What would you suggest?
I a previous job we used Jasig CAS for SSO (several apps in Java and Python). After getting over some quirks in the configuration and my dislike of all things Java, it actually worked pretty well. At the time I found the wiki to be a valuable resource, but things might have changed in the last year.
Authentication was handled via a separate app (custom) using an OpenLDAP directory that was preinitialized with a script that got user info out of an AD server.
Regarding the actual server you might actually want to use the Jasig one, IIRC it's the reference implementation and is easy to customize via a Maven overlay.
Ruby-cas FTW.
here is my scenario, i am building a web application using PHP and MySQL. basically it is a real estate application. where i would like to share the data among several other platforms and devices, here is i what i intend to do
a) building the web app to be used with the browser using PHP, MySQL, and AJAX. (this will be my server)
b) extend the support and build a desktop application using POKKI.
c) extend the support and build an application for Androids and iOS devices.
d) all data transaction for the app should take place from the web server.
e) basically it will be server client application . where the server will be my web server and the clients will be iOS app, Android App Pokki etc.
i am not a hardcore programmer, although it has been more then 1 year since i started using PHP, and i do understand it to my use. i would like to know the best feasible solution on how to share the data among the different clients(POKKI, iOS App, Android App).
i would like to know.
a) do i have to connect to database directly from the client and access the data? is it possible? is it bad if i go this way?
b) do i have to create a public class with api sign up process? what would be the real scenario if i would like it to make it cross platform.
A Humble request to all of you to guide me on how does this things works. any articles, resources, links that can prove useful to me will also be appreciated.
thank you.
I think you should create an API which allows you to access the database strictly as you want it. Look at the twitter API for example and see how it allows third parties to access their data using simple requests.
So your site uses the DB directly where as all other applications you want to make will use the API ( which runs on ur web server)
This would allow you with the flexibility to have control who gets access and who doesnt ( only your own apps or even third parties etc etc) and allows you to build kick-ass applications without putting your actual database at risk.
Hope this helps!
1 - you should not allow client to access data directly - bad.
2 - sign up are easy with open id, let google or any other openid provider handle authentication, you deal with your own clean code without worrying about auth.
http://code.google.com/apis/accounts/docs/OpenID.html
You can create xml api and share the data from your server.
On different type of client you can eaisly parse the xml data and process it or show it.
In xml API if you want the restrict access then your can provide the restriction.
Please let me know if you have any issue
Thanks and Regards,
Ankur K Singh
take a look into getfrapi.com for building API.
A friend and I would like to create a website to manipulate Facebook data.
The structure is:
a PHP web role (contains the web page, user OAuth login, interacts with queues, and interacts with SQL Azure database)
an F# worker role (does statistics and quite heavy data extractions)
The process is (assuming a new user):
user arrives on the web page and logs onto Facebook via OAuth, the PHP web role then posts a message in a worktodo queue with the login info and token.
F# worker role reads the message off the worktodo queue and starts doing data crunching (using the Facebook API) and stats, then it writes the results to a SQL Azure database. Finally it posts a message to the workdone queue stating it has succeeded in doing the data processing for the user.
Finally the PHP web role reads the workdone queue and notices the work is done, and displays the algorithm results.
I have two questions:
Is there a big flaw in this design?
What is the best way to collaborate: one person will write the PHP and another the F#, is there a way to use development storage from two different machines?
Thanks a lot! (Apologies if some find this stuff too basic, I am very much a beginner in all these matters).
If you wanted to follow a bit more experimental path, you could also try looking at Phalanger. This is a project that compiles PHP code to .NET, so it may be possible to run it directly on Azure and nicely collaborate with F# (Phalanger has a few language extensions that allow you to call any .NET objects and some API for calling Phalanger objects from C#).
I was involved in the project some time ago, but it is now beign developed by other people (and as you can see from the check-ins, it is quite active again and they would surely be interested in collaborating to resolve possible Azure issues). If you were interested, let me know - I can give you some contacts, so that you can discuss the Phalanger status on Azure with them.
I don't see anything wrong with this plan.
I don't think there's a way to have two machines pointing at the same development storage, but you can just use cloud storage (even when running locally). I do that all of the time; you will pay for bandwidth and storage transactions, but for most apps in testing, this cost is trivial.