• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Website running off iPhone app's backend?

JMorton6

Senior member
Well, so to speak. What I mean is that I wanna have an iPhone app (social networking category), so I need to get the app itself and the back-end done, but if I want a website too to work off the same script / database, can I just hook that up to the app's back-end so to speak? I'm just trying to figure this out and break the project down into a few milestones. My end goal as I mentioned is an app and website that work together seamlessly. Could someone break down the steps for me please? Thank you! 🙂
 
Create your back end as an API that you can use from both your iPhone app and your web front end.

vvutb.jpg


You're going to do most of your heavy lifting on your back end server. The iPhone app and front-end server should have minimal logic them. The front end should mostly be:
1) Handling user input (validation, etc)
2) Sending the input to the back-end server so it can do the actual work
3) Presentation (HTML/JS/CSS or iPhone GUI). Taking the data response from the back-end and presenting it to the user.

You're going to need to create service calls on your back-end server for your iPhone app. As you're designing your back-end service calls, be careful to make them structured enough that another front-end can take advantage of them. In theory, you could have any number of front-ends using the same back-end.
 
Last edited:
Create your back end as an API that you can use from both your iPhone app and your web front end.

vvutb.jpg


You're going to do most of your heavy lifting on your back end server. The iPhone app and front-end server should have minimal logic them. The front end should mostly be:
1) Handling user input (validation, etc)
2) Sending the input to the back-end server so it can do the actual work
3) Presentation (HTML/JS/CSS or iPhone GUI). Taking the data response from the back-end and presenting it to the user.

You're going to need to create service calls on your back-end server for your iPhone app. As you're designing your back-end service calls, be careful to make them structured enough that another front-end can take advantage of them. In theory, you could have any number of front-ends using the same back-end.

So should I get a mobile app dev to do the API as well as the app, and then get someone else to do the web front-end? Or should the dev doing the web front-end also do the API, so that all the mobile app dev does is create the mobile app?

Also, when you're referring to different servers... I actually plan to use a cloud host, so it would be the same server for everything, right?

Thanks again for your help (and great diagram btw).
 
Leros has it right. I'll try to add something new.

All of your user data is ultimately going to live in a database (ex. SQL Server).

For the mobile app, your best bet is to write web services (ex. SOAP or WCF) that talk to the SQL Server - this abstracts all of your data manipulation into the "cloud" (meaning server based instead of client based). You could even have the mobile app interface generated on the server side and passed to the client (ex. using XSLT), so that you can actually update the look and feel without pushing an update to the client.

For the web site, if your front end is going to be your app/web service server (or they're in the same server farm), you might want to bypass the web services (to save on inherit latency of web service connections vs. direct code calls). You could write your general data manipulation API and just encapsulate them in web services (for your mobile app), leaving the API available for your web site.

I'd recommend finding someone who can do this all for you, instead of trying to farm out separate pieces. As a professional developer, it's always much easier to do good work when you have a full picture of what your client is doing. The skills that are needed for all of this work aren't outrageous - you should be able to find many shops that can do database work + data layer work + web service work + web site work + mobile app development.
 
So should I get a mobile app dev to do the API as well as the app, and then get someone else to do the web front-end? Or should the dev doing the web front-end also do the API, so that all the mobile app dev does is create the mobile app?

Also, when you're referring to different servers... I actually plan to use a cloud host, so it would be the same server for everything, right?

Thanks again for your help (and great diagram btw).

I would suggest having separate server instances (e.g. Tomcat) for your front-end and back-end. You can run them on the same physical machine if you wish.

It's a good idea to have your front-end and back-end in separate server instances.
1) It forces the abstraction layer. This is more important than most people realize.
2) If you set it up right, it only adds a few milliseconds to the response time.
3) If your product gets big and you start needing multiple servers, it helps to be able to pull apart your front-end and back end services. (If your back-end starts to get big, you might even want to break it up into several services).

FWIW, if I were doing this, I would add another server to the diagram I created. I'd have an API server that sits between the iPhone app and the back-end server. The API server handles the communication to the iPhone app uses and uses a nicer protocol to talk to the back-end server.

I'll second what joshsquall said. You should have one development team working on the entire project.
 
Back
Top