So far I've been developing applications where I included services for both web and mobile applications in the single spring boot application where I've used different packages for different clients. But here The problems I faced are like, Since both clients are pointing to the same app in same server, Maintenance became difficult for me for e.g. When I update any service in Mobile part, whole code has deployed and things like this.
I do know it's more generic question.
But here the point in my question is, Is it really a good practice to provide APIs for both web and mobile client from the single application in the Server? Suggest me some good references
TL;DR is, as usual, "it depends" - on size, complexity, team structure and other factors.
Keep going with everything in a single project until a compelling reason to do otherwise emerges.
Related
In Google's latest docs, they say to test Go 1.12+ apps locally, one should just go build.
However, this doesn't take into account all the routing etc that would happen in the app engine utilizing the app.yaml config file.
I see that the dev_appserver.py is still included in the sdk. But it doesn't seem to work in Windows 10.
How does one test their Go App Engine App locally with the app.yaml. ie: as an actual emulated app engine app.
Thank you!
On one hand, if your application consists of just the default service I would recommend to follow #cerise-limón comment suggestion. In general, it is recommended for the routing logic of the application to be handled within the code. Although I'm not a Go programmer, for single service applications that use static_files and static_dir there shouldn't be any problems when testing the application locally. You might also deploy the new version without promoting traffic to it in order to test it as explained here.
On the other hand, if your application is distributed across multiple services and the routing is managed through the dispatch.yaml configuration file you might follow two approaches:
Test each service locally one by one. This could be the way to go if each service has a single responsibility/functionality that could be tested in isolation from the other services. In fact, with this kind of architecture the testing procedure would be more or less the same as for single service applications.
Run all services locally at once and build your own routing layer. This option would allow to test applications where services needs to reach one another in order to fulfill the requests made to them.
Another approach that is widely used is to have a separate project for development purposes where you could just deploy the application and observe it's behavior in the App Engine environment. As for applications with highly coupled services it would be the easiest option. But it largely depends on your budget.
I'm contemplating to use Parse as a platform for my app, as I'm trying to avoid creating and managing the cloud infrastructure myself.
For the sake of simplicity let's say that my app will hook into an Exchange Server and will need to leverage some hosted Machine Learning service to categorize my e-mail and report on insights found.
I'm assuming that Parse would store my core data, while the hosted ML will store the "Big Data" associated with processing for insights.
I'm also expecting my app to receive push notifications generated by the hosted ML service.
Does this sound like a plausible way to go about it and leverage Parse, or am I better off developing the backend myself?
I think parse.com is the right place for you requirements, because they have everything you need like storage of core data, push notifications, cloud module which can be integrated with heroku, social integration, user management functionalities.
They also have large set of client libraries for desktop and mobile apps (node,java,.net etc...) also they have libraries of embedded devices.
The biggest advantage is that everything is setup, and you are focused on software development not on infrastructure things. This is my opinion.
I've been experimenting with the above stack and so far was really impressed. Seems like a viable path forward. The Cloud Code capability of Parse is very solid, and easy to work with. If you want to run services outside of Parse code this us also possible : just issue REST calls.
Good morning,
I am going to write a web service and I am not sure which framework would suit the situation best. I understand what Node and .Net are good at.
The client will call the services at the following stages:
App loads up - user logins in via Facebook API.
User can create an "entity". This entity will be stored in a database (SQL for .Net/ Azure table for Node) and also posted to a Facebook application (timeline stuff). User can make changes to this at any time.
User can browse Facebook Friends (Facebook API again).
Changes to the entity will be pushed to all users who have "joined" the same entity (SignalR .net/Socket.io Node).
That is the skeleton of the web services, there may be more Facebook calls or CRUD operations. Which Framework will handle this best?
Many thanks.
Aside from the mentioned WebAPI, also consider the excellent ServiceStack for building a webservice.
Any well-written code regardless of the framework will be able to handle it.
If you are a .NET developer I personally think type safety of C# is important so I would not go down the Azure node.js way since it will also force me to use Azure.
I would personally use ASP.NET Web API.
As long as you build your application on a solid framework, you'll be on the bright side (assuming you know how to set-up such an application in a secure and proper manner). For .NET i'd use the Web API and for node.js i'd stick with something like express/connect.
Just keep in mind that node.js and the frameworks based on it are still subject to heavy changes, whereas ASP.NET is production-safe since years.
As a bottom line, i don't think you're able to say "X is better than Y because of Z" in this scenario. It's a matter of personal preferences, infrastructure and your technical skills.
I am wondering what the best way is to share authentication, session management, etc. across a web site with both a mobile and desktop version. We are running Tomcat, and prefer to keep the mobile and the desktop sites separate applications on separate nodes.
I have seen similar posts regarding persisting the session throughout Tomcat applications, but I'd prefer to do this through the app alone. I've read about clustering in Tomcat, but that appears to be for a single app running across many nodes.
Is there a common way to do this? How do other sites handle session management across mobile and desktop versions?
if I understand correctly you are implementing you mobile and desktop versions of your site as separate web applications. Sharing sessions across multiple apps is not part of the j2ee specs as far as I know; in addition to that I am not aware of any product that offers the functionality..
..So, that would leave you with the option of implementing your own :)
one obvious approach would be to use the db to store session data instead of HttpSession; I'm not saying this is easy; actually may be a good reason to reconsider the decision of having two separate apps for the same site
I got a lot of theoretical answers from Google that WCF is better than Web Service etc. etc. But I want to know from the programming and implementation point of view. I am very new to coding and want to know that how do we implement all three of these technologies? How are they different and in which scenario we should used which technologies?
Thank you in advance.
A web service is an API that is hosted for access via a network connection - often the internet - and usually accessed over HTTP (or HTTPS).
WCF is a Microsoft .NET development framework that can be used to implement web services. That is, WCF-services are a subset of all web-services.
Windows services are a separate beast entirely: they are long-running programs that run on your local Windows machine, typically with no user interaction and on system accounts. They are used to handle many things in Windows, from low-level driver functionality to software updates.
You're really comparing apples and oranges. A web service is simply a program that you can "call" using the HTTP protocol. Typically, HTTP requests sent to the service contain some XML describing the method called and any parameters. The response from the service likewise contains XML with the return value and any output parameters. It's a little more complicated than this, but it gives you the basic idea.
Windows Communication Foundation (WCF) is a framework for building network services. You can use this framework to build web services if you wish. I suspect that what's tripping you up are the various Visual Studio project templates. You have one for WCF services and one for web services. The web service template builds a web service that runs inside of IIS. The WCF template gives you far more flexibility (you can make a web service as a stand-alone application, for example), but it is far more complicated.
If you're just beginning, I'd start with web service template and IIS-based web services.
MSDN is always a good reference:
Web Service Tutorial:
http://msdn.microsoft.com/en-us/library/8wbhsy70%28VS.80%29.aspx
WCF Tutorial:
http://msdn.microsoft.com/en-us/library/ms734712.aspx
I think its always easier to learn by doing.
Good luck