I have a few question about the remote deployment of functions as shown the diagram:
If have remote statefun functions (multiple instance with the Undertow as shown in the examples fronted by api gateway):
Do we need to configure the api gateway to send calls with same url to the same backend hosting the function or does the frame work take care of it ?
From my understanding each function is keeping local state. If one instance is relocated, or we scale the functions, how does the local state get redistributed ?
If there is any documentation, on this, please let me know.
Thanks.
The functions are stateless. All of the state they need in order to respond to an invocation is included in the message, and the response will include any updates to the state that are needed. Because they are stateless there's no need to worry about sessions or instance affinity or rescaling for remote functions.
The developers have given talks that get into some of these details. I'll suggest a talk by Tzu-Li (Gordon) Tai, Stateful Functions: Polyglot Event-Driven Functions for Stateful Distributed Applications.
Related
I added a WebSocket API through AWS API Gateway on my React app.
I originally added it to build a chat messaging section, however, I soon realized how useful it could be for other things in the app that might need real-time updates.
I had an idea, and that is to store the socket in a React context so it's accessible from all the components of the app and that should work fine, without re-establishing a connection every time a component mounts.
Now, the question is, is there a better way to do what I'm trying to do? Hence, create a socket connection that I can then take advantage of for multiple functions? Say for instance, "is online" status.
The alternative is to create yet another socket API but is that really necessary?
Keep in mind I'm using a serverless framework (API) with lambda functions on AWS.
This is going to depend on the applications planned scale, keeping in mind that as the app usage grows you may want to refine the endpoint architecture and code.
Remember that an auth endpoint/api for example may only need to be accessed a few times over a chat interaction endpoint/api. For scalability (and cost per endpoint call too) id be looking at keeping them separate.
I am building a multi-player Todo app. I am sending the entire todo state to the server and the server broadcasts it to the other clients. How can I use SyncState and how will it be efficient?
In case of SyncState, we send patches for communication. Patches, in general, is just the change in the current state. This allows us to send only the required data and not the entire thing, thus reducing the size of data being transferred. Doing this also provides us with a few more benefits:
A way to track history
Snapshots can be created and traced using patches
You can refer to the talk by the creator of SyncState for more in-depth explanation of using JSON patches for building multi-user apps.
I want to be able to monitor issues from mobile application like from backend micro-services.
I'm not aware of any real time monitoring for mobile applications outside.
I think that it can really help to monitor mobile application and report errors from the application and not only from the backend services. Sometimes the application is connected to multiple services and has its own logic so it seems like one place to catch all errors and wrong behaviour.
Are there any tools outside?
If for example I'll use mParticle/Segment as Hub to report events, can I connect it to Graphite somehow which is push-based monitoring ? Maybe through SQS / AWS Lambda ?
https://www.mparticle.com/integrations
In theory, yes it's possible to send data to Graphite using a combination of SQS + Lambda. I've tested this by writing some metric data to SQS and used a node js lambda function to read and forward that data to our carbon endpoint at https://hostedgraphite.com via UDP per our language guide here
Having said that, there are some further considerations that we must take in order to ensure this works: the main one being data format. Graphite/Carbon require data in a specific format, something that mParticle might not support directly. As such, you will need an AWS Lambda that formats the messages and then forwards to Graphite (or optionally, to another SQS queue where another Lambda reads and forwards that data to Graphite).
I'm trying to figure out how to create an offline / online approch to use within a huge application.
Right now, each part of the application has its own model and datalayer, who directly read / write data from / to SQL. My boss is asking me to create a kind of buffer that, in case of connectivity failure, might be used to store data until the connection to SQL return active.
What I'm trying to create is something like this: move all datalayers into a servicestack service. Each "GET" method should query the database and store the result into a cache to be reused once the connection to SQL is not available. Each "POST" and "PUT" method must execute their actions or store the request into a cache if the connection fail. this cache must be cleared once the connection to SQL is restored.
How can I achieve this? Mine is a WPF application running on Windows 10.
Best regards
Enrico
Maintaining caches on the server is not going to help create an offline Application given the client wouldn't have access to the server in order to retrieve those caches. What you'd need instead is to maintain state on the client so in the event that network access is lost the client is loading from its own local caches.
Architecturally this is easiest achieved with a Web App using a Single Page App framework like Vue (+ Vuex) or React (+ Redux or MobX). The ServiceStack TechStacks and Gistlyn Apps are good (well documented) examples of this where they store client state in a Vuex store (for TechStacks created in Vue) or Redux Store (for Gistlyn created in React), or the Old TechStacks (created with AngularJS).
For good examples of this checkout Gistlyn's snapshots feature where the entire client state can be restored from a single serialized JSON object or approach used the Real Time Network Traveler example where an initial client state and delta's can be serialized across the network to enable real-time remote control of multiple connected clients.
They weren't developed with offline in mind, but their architecture naturally leads to being offline capable, courtesy of each page being first loaded from its local store then it fires off a Request to update its local cache which thanks to the reactivity of JS SPA fx's, the page is automatically updated with the latest version of the server.
Messaging APIs
HTTP has synchronous tight coupling which isn't ideal for offline communication, what you want instead is to design your write APIs so they're One Way/Asynchronous so you can implement a message queue on the client which queues up Request DTOs and sends them reliably to the server by resending them (using an exponential backoff) until the succeed without error. Then for cases where the client needs to be notified that their request has been processed they can either be done via Server Events or via the client long-polling the server checking to see if their request has been processed.
Couple of questions:
I have list of components on the client app which has some near real time info e.g. status, which I want to display.
I have server app, which can pull the status info from a third party REST endpoint.
My question is, should I cycle through all the components in the client app and request the server app for the status?
Or should I have a server worker thread, which pulls the status info and publishes on the websocket, which the client can then update the state of the component.
Or is there background thread which I can run on the client app, which will update the status and the state. How will this conflict with the dispatch/queuing of events from user interactions.
I think I might be asking some of the architectural questions and the answers might be "it depends" ambiguous, but anyone who has done this before and any guidance is appreciated.
Thanks, Rajesh
It depends :) But it's safe to go with server-side approach since with client-side you would have to deal with CORS and cross-domain ajax calls in general. Most of the 3rd party API do not allow to make arbitrary AJAX calls from other domains. Those that do allow that usually have API quota which is again easier to manage since you can keep your keys secret on the server and throttle and cache requests.
Server side approach requires more effort though. So it's a prototype and 3rd party API allows cross-domain requests – go for it, it's easier, for production app, consider doing this on the server.
For client-side approach if 3rd party API doesn't offer subscriptions, yes you would have to poll, but you don't have to cycle through components. You can abstract this polling in one, root component and then just pass props down.
You are right, the answer is "it depends".
Basically, you have two options:
Poll the server for the current status.
I believe you do not have to cycle through all the components and query their status. You could just have an API that provides the server the timestamp when you last queried the status, and the server will respond with just the information that has changed since the last query.
This is simple and will work fine if the updates are not huge, and you can afford to be a little late.
You could have a dedicated websocket connection with the server
In this case, the server will push any new updates to your front-end whenever any new update is available. This is a little cumbersome to implement, but is the right approach if the updates are near real-time.
To answer your question about having a background-thread on the front-end: no, you cannot have background-threads on the front-end. Javascript doesn't work that way. What you do have are callbacks. Whenever the server pushes you any new information, a callback, that you define, will be called and you can do whatever UI changes you need from here.
My question is, should I cycle through all the components in the client app and request the server app for the status?
No, this sounds very inefficient to me.
However, if you decide to poll from the client, it should be done only from a single component that is parent to all children that need the information. The parent then passes its state to the children and they update on each poll.
Or should I have a server worker thread, which pulls the status info and publishes on the websocket, which the client can then update the state of the component.
Absolutely. Let this socket be in your top-level application component which holds the real-time info in its state and passes down to its children. Whenever information gets published to the socket, update the top-level application state with the new real-time info and all children will rerender displaying the most current information.