I have been looking for the answer for this question but it was a bit tough for me to come up with the query (question) itself. So if there is already good answer for the below question i would be very grateful for the link.
Let's assume I have an e-commerce web site and an API endpoint for future calls from mobile apps. My question is: should I duplicate logic for querying let's say product for product page on website or should I consider website as an API client and displaying product info by making CURL? request to API.
I suppose I should stick with last one. But I am concerned about making extra curl(TCP/IP) request within script. Will it be significantly slower for the overall response time? Are there any other "patterns" I am not aware of? Thank you.
Sites are on same server but API uses Phalcon PHP and website uses regular PHP
Duplication is definitely the wrong thing to do.
Technically, you have three options:
move the shared business logic to a separate repository and reuse it in both project as private composer package
use cURL/socket wrapper library to access the API (probably using Guzzle)
make public calls to the API using JS (preferably via fetch)
Each of these was drawbacks, so your choice would depend on which option hurts the less.
The shared library would have the best performance, but it would complicate the deployment process and there will be situations, when those applications (site and api) will have contradicting requirements. The problems are organizational.
Internally calling the API server over HTTP will make the site be a lot less responsive (since the TTFB will be a lot longer), but it would let you leave the API code completely unchanged.
Having it all in public comes with security and authorization problems. But, depending on how you expect the mobile API clients to be made, this could be seen as future-investment. But it will require substantial development time and someone who is skilled with javascript (maybe even with JS frameworks), since your website would have to be heavily altered. Most development-intensive option.
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'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
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!!!
We have built an electronic ticketing system using plain PHP and MySQL. After learning this system needs to be accessed on portable Android devices we hired an app developer to build us a simple app.
What is interesting is the app (from screenshots) functions almost identical to the web system we created. The app developer said after it's completed it will not rely on our system but communicate directly with the database. In the future if we update our PHP system he said we can update the app.
I'm just now learning how to develop Android apps. From what the app developer is saying it appears he's simply translating (compiling?) our code into an app. Is this possible? I'm aware there's a new method in building Android apps with PHP, but I seriously doubt he's doing that. Am I missing something, or did we just waste funds when we could have done something ourselves?
It isn't possible to run a PHP application on an Android device, no. However it could be running a lightweight browser inside an app, which accesses your website. Try making a small modification to your live site and then access the site again from your mobile device, to see if it changes.
The app developer said after it's completed it will not rely on our system but communicate directly with the database.
You don't want to communicate directly with the database - that sounds like it would require MySQL to be left open to the internet. That's not ideal from a security perspective (I don't know if Android has the drivers for it anyway). Instead, you should run an AJAX web front end and send commands (but not SQL commands) to the database that way, cleaning/untainting the input data thoroughly. Indeed, maybe that is what he is referring to?
or did we just waste funds when we could have done something ourselves?
It's difficult to answer that. If you discover something useful as a result of employing him, perhaps it was worthwhile? Of course, this illustrates that it is important to know the technical environment thoroughly when hiring someone, and perhaps when you hire someone in the future you'll discuss their technical solution prior to implementation. If you decide to pull out at that stage, pay them for the R&D and the technical spec, and do it yourself.
In any case, why wonder about it? As part of completing this item of work, ask for technical details of his implementation on both the mobile and server side. And of course don't forget to ask for the source code - hopefully it was written into the contract that you own this intellectual property.
So, i've been reading a lot on SOA's lately and been trying to implement something useful. I have started with a simple blog, creating the RESTful API. So far, so good. It works perfectly. However, i'm starting to pull my hair off when writing the web interface that will consume the RESTful API. I don't know if i'm doing the right thing.
For example, the web interface has an admin panel. That admin panel makes HTTP requests to the API, through file_get_contents and stream options. Right now, the API is localhost, as well the web interface, but the whole process is a little slower. Is this right? Is this the proper way of implementing a SOA? Also, i'm dealing with little bits of duplicated code for validation. Where should i validate data? In the API or the web interface? What is the best approach?
Tips, tutorials and, specially, books are welcome. This is being implemented using Silex, built on top of Symfony components.
That's exactly how i do it. Although the connection with localhost might seem an overhead at first, it is a feature, since you're ready to deploy your web interface application anywhere and still consume your API, that might be anywhere. Of course, you would put some SSL over this.
As for Validation, you should validate on the API and return HTTP status codes for those situations (for example, "400 Bad Request" for invalid parameters). This way, any other client can interpret the response from the API and treat that to display how they want. In the case of your web interface, nice little error messages based on the HTTP status code.
What other problems are you facing? Also, as far as general SOA architecture is concerned, this book is very good.