Currently I have UI Client(React) and searching for some approaches for translation.
Could I consider using AWS Translate
So is using AWS Translate will be an option or what is the drawbacks for this as I am caring about the latency as whenever the customer will refresh then this will call the translation whenever there is refreshing.
Do there is current UI application which is using AWS translation
and what is the alternative solution for translation from UI
Thanks
Related
We have our old 'Camunda based Spring boot application' which we currently deployed it into kubernetes which is running in an AWS EC2 Instance. This application acts as a backend for an angular based UI application.
Now we need to develop a new application similar to the above, which needs to interact with UI.
Our process flow will contain some UserTasks (BPMN) which will wait until manual interaction performed by human user via angular UI.
We are evaluating the possibility of using AWS stepfunctions instead of Camunda, if possible.
I googled but unable to find a concrete answer.
Is AWS stepfunctions have any feature similar to BPMN/Camunda's UserTask ?
Short answer: No.
====================================
Long answer:
After a whole day of study, I decided to continue with CamundaBPM because of below reasons.
AWS step-functions don't have an equivalent feature of UserTask in BPMN.
Step functions supports minimal human intervention via sending emails/messages by using AWS SQS(simple queue service) and AWS SNS(simple notification service).
Refer this link for full example. This manual interaction also based on 'task token'. So this interaction is limited to basic conversational style.
Step-function is NOT coming with in-built database & data management support, the developer has to take care of designing database schema, creating tables, their relationship etc.
On the other hand, Camunda is taking care of creating tables, their relationship, saving & fetching data.
No GUI modeler is available in step-functions, instead you need to draw workflow in a JSON-like language. This will be very difficult if your workflow becomes complex.
Drawing workflow in Camunda is just drag-and-drop using it's modeler.
There are numerous articles such as this one, which insist that while implementing microservices, each team should build its own UI. These fragments can be composed into a single page using iFrames or div.
My question is, how to implement using AWS.
This could be done at deployment time, or runtime.
1. Deployment time: HTML fragments need to be collected as part of CI/CD process and put together in S3 which serves as web server for static pages (API GW for dynamic JSON content).
2. Run time: The html fragment (div)will have to be delivered to client browser on demand, as and when client clicks through (can be cached in client browser, and/or API GW.
What is the technology for this? I don't think Lambdas can deliver HTML fragments through API GW. Also, the CI/CD approach appears to be fuzzy to me.
Btw any other way? Thanks
Use SPA like angular/react (but not limited to. Same method can be implemented in MPA).
SPA helps us to segregate the UI from the back-end and both runs independently.
And in the service layer of the application(UI), call the respective micro-service say M1 or M2.
In monolithic applications like MPA (multi page application- spring/struts/jsp) where the UI is generated from the back-end and are tightly coupled you need to call different rest-api using jquery/ajax and process the JSON response.
In SPA multiple scenarios like parallel trigger all micro-services or wait for M1 and pass the payload to M2 or race between M1 and M2 can be achieved using promises in javascript
I've just started messing around with AWS DynamoDB in my iOS app and I have a few questions.
Currently, I have my app communicating directly to my DynamoDB database. I've been reading around lately and people are saying this isn't the proper way to go about getting data from my database.
By this I mean is I just have a function in my code querying my Dynamo database and returning the result.
How I do it works but is there a better way I should be going about this?
Amazon DynamoDB itself is a highly-scalable service and standing up another server in front of it requires scaling the service also in line with the RCU/WCU configured for your tables, which we can and should avoid.
If your mobile application doesn't need a backend server and you can perform all the business functions from the mobile device, then you should probably think about
Using the AWS DynamoDB SDK for iOS devices to write your client application that runs on the mobile device
Use AWS Token Vending Machine to authenticate your mobile users to grant them credentials to be used to run operations on DynamoDB tables.
Control access (i.e what operations should be allowed on tables etc.,) using IAM policies.
HTH.
From what you say, I can guess that you are talking about a way you can distribute data to many clients (ios apps).
There are few integration patterns (a very good book on this: Enterprise Integration Patterns), one of which is called shared database. It is essentially about using a common database for multiple clients to share the data. Main drawback for that pattern (in your case) is that you are doing assumption about how the database schema looks like. It can potentially bring you some headache supporting the schema in the future, if your business logic changes.
The more advanced approach would be sending events on every change in your data instead of directly writing changes to the database from client apps. This way you can add additional processing to the events before the data they carry is written to the database. For example, you may want to change the event format in the new version of your app, but still want to support legacy users, so you add translation procedure which transforms both types of events to the format which fits the database schema. It's basically a question of whether to work with diffs vs snapshots.
You should be aware of added complexity of working with events, and it can be an overkill if your app is simple and changes in schema are unlikely.
Also consider that you can do data preprocessing using DynamoDB Streams, which gives you some advantages of using events still keeping it simple to implement.
com Developer and working on an integration app that links an external system with Salesforce.com. The external system exposes its service through SOAP API and provides a WSDL which I have imported and classes are created under a namespace. I need help in developing the overall architecture of the application.
What should be the architecture of the system? Should I develop model and service classes for different entities for fetching data from external app and converting response into my own model classes?
Treat the external system as you would a typical data layer (DBMS, Web services, etc). This means encapsulating the data fetching logic in such a way that the business layer has no idea where the data is coming from. The Repository Pattern is one technique for doing this.
Once you have abstracted your data layer away, you would handle the translation of Data to Entities in whatever way you see fit. You could use a tool such as AutoMapper to do this or write your own custom translation layer where the Data is translated into objects that your application works with.
Nowadays a lot of web applications are providing API for other applications to use.
I am new to the usage of API so I want to understand the use cases for it.
Lets take Basecamp as an example.
What are the use cases for using their API in my web application?
For inserting current data in my web application into a newly created Basecamp account instead of inserting everything manually which could take days or weeks if the data is huge?
For updating my application data when the user changes something in Basecamp. If so, how do I know for example when a user add/edit/remove a contact in Basecamp. Do I make a request and check every minute from the backend?
For making backup of the Basecamp data so I can move it to other applications if necessary?
Are all the above examples good use cases for the usage of API?
Are there more use cases?
I want to have a clear picture of why it's good to use another web service API and how I can leverage that on my application.
Thanks.
I've found the biggest reason to use and provide web services is to be able to programmatically drive the application with another process. This allows the coupling of different actions in different applications driven by one event/process/trigger.
For example I could create a use a webservice provided by Basecamp, my bug tracking database and the continuous integration server. I could tie all those things together and kick them off from a commit hook script.
I can have a monitor in production automatically open a ticket in our ticket tracker. This could trigger an autoremediation process from the ticket tracker which logs into the box remotely and restarts the service.
The other major reason I've seen to use and provide web service is to reduce double entry. If you do change management in your production environment that usually means you create Change tickets. The changes that occur may also need to be reflected in the Change Management Database which is usually a model of how production is suppose to look. Most of these systems don't automatically drive the update of your configuration item with the data from the change. Using web services you can stitch them together to eliminate the double (manual) entry that would normally occur.
APIs are used any time you want to get data to/from an application without using the default interface.
*I'd bet there's a mobile app would use the basecamp api.
*You could use the api to pull information from basecamp into another application (like project manager software or an individual's todo webpage)
*the geekiest of us may prefer to update basecamp from a script/command line rather than interrupting our work flow to open a web page and click around.