I've been working on the React Native platform this last couple of months and I need to implement a solid way to handle my API calls. At the moment I'm using redux to manage satate changes. Obviously the requestes must have a couple of retries if there is no network available, refresh oAuth tokens, etc.
Three solutions have ocurred to me:
Implement a "manager" class and handle all the logic in there. I like this one but I don't know if is possible to connect a non-component to redux since they dont have state.
Implement a couple of redux actions(request, onResponse, onError...) which should do the trick.
Create separated redux actions with their own fetchs to every call instead of having a centralized component.
What solution should I implement?
Another problem I've faced is that if a Network Error happens the promise is resolved even if I call the request again and I'm no longer able to make the behavior programmed in the caller method. Any workarounds?
Thank you for your time.
Redux has two powerful libraries that are designed to work with async API calls. These allow you to handle retries, errors, and slow API calls in the background of your app, simply by listening for a specific action.
Redux-thunk or Redux-saga are what you are probably going to want to use, so that you do not have to do all of the work of managing how components deal with API calls. Strongly recommend you check these out - there are quite a few tutorials out there that describe how to use these modules. Doing this by hand is not a good best practice IMO.
For api handling. you can have one single file which will have all function (export) and other settings needed so that you just have to import required methods.
You can use starter kit for react-native for basic structure for example: https://github.com/futurice/pepperoni-app-kit
it provides most of the things that we need for fresh project setup.
Follow the pattern mentioned in the below tutorial(youtube link below)
https://www.youtube.com/watch?v=9mlwjZL3Fmw
Everyone uses this pattern for API calls when following redux in react-native.
The tutorial is really good,its a great video.
Related
I am using fastapi for the first time in a project.
I receive information from an html form and return a HTMLResponse object to indicate that the program is running in the background (thanks to the BackgroundTask object). Is there a way to return another HTML file and to make my browser switch to that once the background task is over?
Sorry if I use the wrong terminology, but I am no expert.
Cheers
So what you need to do here is implement websockets. After your task is finished you can have to send a message on the websockets intimidating that the task has finished.
Think of it like a notification service.
You can find some documentation here
You will have to connect to the websocket from your frontend as well.
Do you research on this, I'm sure you will find a lot of documentation and articles on this idea.
I normally develop with ASP.NET MVC, but I'm very new to Blazor. I'm creating a new site in Blazor WebAssembly. The very first thing I need to do is create a page with a simple form, that can create or update an item and send it to the server, to be saved in the DB. I can either send the object using SignalR, or use HttpClient to post it to a controller action. What's the best practice here in Blazor Wasm? I was tempted at first to just use SignalR all the time.
I've seen examples of using both, but very little to help decide which to use in what circumstances. This was about the most useful thing I could find but it doesn't answer the exact question and it's also not specific to Blazor.
The question is specifically about the simple create update operation, but other pros and cons of both would be very helpful. Is it as simple as "only use SignalR when clients need to listen for messages from the server, to avoid having too many open connections"?
Thanks a lot
Is it as simple as "only use SignalR when clients need to listen for messages from the server, to avoid having too many open connections"?
Yes, I think it is. CRUDL operations are transactional and asynchronous. Do a transaction, wait forever on the user, do another transaction,.... I would always do these through an API Get/Post.
The only time I would consider SignalR is where I'm passing object defined objects - such as a Dictionary<string, object>. They are a pain in controller API calls.
We are building a platform based on microservices. The platform will provide a number of basic functions that will be used in various independent projects.
We need to come up with such an architecture that will allow us to extend the basic functionality and interact with existing services. The main task is to ensure that the code of the main services remains unchanged, and custom solutions based on the platform can be easily reused.
We are considering several options. For example, there is a certain service "foo" which provides the functions foo1 and foo2. To extend the functions, we can create an independent "foobar" service and put it in front of the foo service, accept API requests, execute custom functions, and then redirect the request to foo. It turns out a kind of intermediary service, which acts as the main link in the implementation of the functions specific to a given project and the main platform. The advantage of this approach can be attributed to complete independence from the code base of basic services. And the main disadvantage is the complexity of implementation and the need to greatly fragment the functions of the main service.
The second option under consideration is similar to the approach that is often used in monolithic applications - the hook system, which allows you to override the behavior of the system. For example, you can create an independent service that will connect events and subscribers.
This approach is more flexible, but at the same time it is still quite difficult to implement. The main disadvantage of this approach is synchronous blocking network calls.
The third option that we are considering is the construction of the microservices themselves in such a way that additional modules can be added to them so that services can be customized at the build stage. The main code remains unchanged, but inside the process, the already mentioned scheme of hooks and events is implemented (at the code level of individual services). Benefit is ease of implementation. Of the cons, it is very difficult to implement customizations in the case multiple services are involved.
Perhaps we are trying to invent a bicycle and there are exist good solution(s) for the problem. If you know such, or you have a good idea about possible ways to solve this problem, please share.
I don't think there is an answer to this generic problem. The third solution seems pretty good. You might take advantage of chain-of-responsabilities or request-response pipelines paradigm to implement the open/closed principle pretty easily. This should ensure that you can add/modify features into your foo service without touching the existing code.
If you are looking for something to tackle to whole architecture rather than a single microservice, you might want to give a look at the Event-Driven microservices design.
This design approach is similar to your option 2, with the difference that it uses a message broker and async communication to let the microservices communicate.
There are a lot of advantages, like more resiliency and decoupling of the services.
I'm trying to refactor an existing project into PureMVC. This is an Adobe AIR desktop app taking advantage of the SQLite library included with AIR and building upon it with a few other libraries:
Paul Robertson's excellent async SQLRunner
promise-as3 implementation of asynchronous promises
websql-js documentation for good measure
I made my current implementation of the database similar to websql-js's promise based SQL access layer and it works pretty well, however I am struggling to see how it can work in PureMVC.
Currently, I have my VOs that will be paired with DAOs (data access objects) for database access. Where I'm stuck is how to track the dbFile and sqlRunner instances across the entire program. The DAOs will need to know about the sqlRunner, or at the very least, the dbFile. Should the sqlRunner be treated as singleton-esque? Or created for every database query?
Finally, how do I expose the dbFile or sqlRunner to the DAOs? In my head right now I see keeping these in a DatabaseProxy that would be exposed to other proxies, and instantiate DAOs when needed. What about a DAO factory pattern?
I'm very new to PureMVC but I really like the structure and separation of roles. Please don't hesitate to tell me if this implementation simply will not work.
Typically in PureMVC you would use a Proxy to fetch remote data and populate the VOs used by your View, so in that respect your proposed architecture sounds fine.
DAOs are not a pattern I've ever seen used in conjunction with PureMVC (which is not to say that nobody does or should). However, if I was setting out to write a crud application in PureMVC, I would probably think in terms of a Proxy (or proxies) to read information from the database, and Commands to write it back.
I'm having some conceptual trouble on figuring out how to best implement this... I want to create a custom Activity class for Windows Workflow. The activity has to call out to a third party library method that itself runs another process asynchronously and may take anywhere from seconds to many hours to complete. This library offers the ability for me to either poll for the method result or to subscribe to an event that indicates its completion. In my non-workflow apps, I typically just subscribe to that event, but that doesn't seem to be reasonable in the workflow case. I'm also not sure exactly how to best implement a polling scheme. Can someone recommend some pointers to similar problems?
Kirk Allen Evans wrote an interesting blog about this with some pretty good code examples.