We wanted to create a mobile app using flutter, I searched on how to connect odoo with external platforms or apps , I found there are two solutions:
The most common and standard one is to use the xmlrpc communication protocol, we did found some libraries with that name in flutter , but the problem with this is that it's a bit complicated for flutter devs that does not know how the Odoo architecture works.
The least common method is the endpoints or controllers method, basically you create endpoints in your controllers and just call it through http request from the mobile side, the problem with this method is that it's not standard and I did not see much people talk about it, I also heard that this method is for the web instead of mobile apps since the session_id of the identification is returned in the Cookies.
My question is the following, is the endpoint method good enough for mobile app? If no, are their any alternative of xmlrpc?
You can connect odoo with the flutter app using simple RESTful API requests, there are many packages in pub.dev which can help you
Related
I want to create web app in Nextjs and in the future mobile app in React Native. But I am confused what api to use. Do you think that the Nextjs api can handle both web and mobile apps? Is this possible and is it good idea at all? Should I use PHP backend for that? Thank you very much.
With the assumption that you are talking about API Routes :
I would ask you that you think through the scale of your web and app. If this is a simple web/app that you do not expect to grow much - The NextJS API which is similar to standing up an nodejs express server is not a bad option.
Remember a few considerations when designing this API
You may have to distinguish the request origin (web/app)
CORS may have to be customized - Next exposes this
You could set an app specific route to ensure isolation or use headers to distinguish behavior if your application bifurcates in the future.
These concerns are shared even if you made a PHP, ExpresJS or any other API middleware.
Once you are past all this, i would ask you to consider
Using a GraphQL server like Apollo that works nicely with Next and is custom built for this purpose..
Evaluating API Gateways for security and scale.
You don't use any external tools at all.
Next JS has serverless model. So, you don't need to mess with BE.
You can create a number of API routes you want. in /pages/api folder. You can even split like /pages/api/desktop and
/pages/api/mobile folders.
You connect your database (MongDB, sql etc) via /middleware/your_file.js. Here is example for MongoDB
If you like, you can even add some security (ex: Auth0, next-auth
etc) to secure your API routes created in /pages/api folder. Example for Auth0
After, you can access you data througth API calls. Very good!
I am building a Xamarin iOS Native project for a iPhone app and i am using Google Maps for creating Routes to several delivery points.
I registered for the Google Maps API but i have troubles with the security of the API key.
In my project i have installed the Nugget package for Xamarin.Google.iOS.Maps and set the App restrictions to my iOS Bundle name. When initializing the MAP all works fine.
BUT we also use the Direction API for setting up routes to different points of the map. But this call function method is a HttpClient call to a JsonAsync call. The Google API denies the call because it did not work with the Bundle name because its a HtppClient Call.
The project is installed on Mobile devices so restricting with a IP address is not a option for us. No restriction AT ALL is also bad for the security.
So my question is : How do I secure this?
Please note that web services cannot work with API keys that are Android/iOS restricted. Web services are server-side and can only work with API keys that are either unrestricted or restricted by IP address.
To resolve your issue, please create a second API key to use for web service requests only.
The public docs on best practices when using API keys has also some suggestions for when IP address restrictions are impractical as with the case with mobile applications.
When using Maps Web Service APIs in these scenarios, secure your apps using one or more of the following techniques:
-proxy server
-obfuscation
-pinning
References:
https://developers.google.com/maps/api-key-best-practices#api_key_table_sup_5
https://developers.google.com/maps/api-key-best-practices#proxy_server
I want to build an instant chat app with flutter without any third party services.
I've been working in a simple app using a restful laravel api for login, multiple methods and logout, using token authentication for each request. However, I find that architecture not suitable for a modern instant chat. I discovered WebSockets, which sound great, but can't yet grasp how I could subscribe to and consume one from flutter. I´ve read about web channels, but I'm not sure how they handle authentication for users. Is it possible to handshake and establish a session from my app? If so, how?
Or, can it be done totally restful? How could I post messages and listen other user's messages in that case?
Besides the chat functionality, is it recommended to work restfully? Or is flutter able to mantain a solid, authenticated session? I'm kinda new in flutter.
I appreciate any info, link or recommendation. Please, refrain if you were going to mention firebase, I want to build my own backend. Thanks!!
You should check out MQTT, an IOT protocol which is currently used for chat applications very widely.
To know about MQTT, see this.
But first I will recommend you to understand Pub-Sub(Publisher-Subscriber) Model, if you understand it then that's great.
For pub-sub model, see this.
Or, can it be done totally restful? How could I post messages and listen other user's messages in that case?
Yes, it can be done totally restful but honestly it's not recommended. You should do it with websockets.
Besides the chat functionality, is it recommended to work restfully? Or is flutter able to maintain a solid, authenticated session? I'm kinda new in flutter.
Depends on your architectural choice. There are many good options on which architecture you want to choose. Apart from restful there is GraphQL also, if you are comfortable with it. Apart from chat functionality mostly you will see people using RESTful but people who know GraphQL, might also use that instead of RESTful.
I'm planing on creating an native .net app for Windows as well as a native OSX application with swift.
These two applications should be able to communicate with the same server. With that I mean writing and reading from the same SQL Database, and have REST communication with the server.
Now I'm struggling to come up with a solution for the backend. I'm looking into Serverless backends like Azure or Google Cloud, but I'm not sure that I can use these Services with both my applications. Both Azure and Google Cloud have SDKs for .Net but I've never found one for Swift or Objective-C.
Are there such Services that allow me to communicate or should I just develop my own?
Do you have any good solutions for my problem? Or what is the best server architecture to use for this kind of problem? Any inputs are appreciated!
If your servers vend a REST API, no vendor SDKs should be required. REST is platform- and vendor-agnostic. All you need is an HTTP client, which Swift/ObjC most definitely do have. I use a serverless (AWS Lambda) setup from Swift, and it's easy. Though, I have done this kind of thing before :)
What I would do is setup a simple test server, and expose an API endpoint. Make sure you can reach it with curl from your machine. Then, take a look at the NSURLSession APIs in Foundation. They'll help you make an HTTP request similar to what curl can do. From there, you'll need to investigate serialization (like JSON), which Swift can also do easily (as of Swift 4, I believe).
Good luck!
I'm architecting a public web API for my service. It will be equally consumed by web pages and native mobile apps (iOS, Android and Windows 8).
Should I use cookie-based authentication? I mean, is this the best practice for this scenario?
Futher Info:
After a little research in the authentication/authorization/openId-connect field i realized that most of everything is handled by the browser, by that i mean, the redirects, coockie insertion and related "boiler-plate" stuff... when i think about all that boiler-plate that i will have to duplicate in my natives apps, i wonder if that model is the best for mobile apps. i mean, maybe theres another more mobile-native-friendly way...
Ps: i know that this is a little generic still, it's just that i'm a begginer in the field of security and i dont know how to properly express my doubts/concerns/"laziness" still...
The API itself should really be stateless, and not manage any sessions. Each request to an API should be made with the authentication details (e.g. OAuth token).
If the Web pages and mobile applications need to maintain some kind of session, then it should be up to them as clients of the service to maintain that state. For instance, a Web page might set a session cookie for the user, but a native mobile app might want a completely different approach.
See also: If REST applications are supposed to be stateless, how do you manage sessions?