Modern serverless apps still require state and asynchronous longer-running processes...
Rapid prototyping and development
API | State | Integration
The essence of an API | function
The first step is designing a nice API for the services you need: decouple the API's form from the function and design the conceptual API. Let's take the classic example of a cart service...
$msg cart.get (customerId) : (cart)
$msg cart.addItem (customerId, sku, quantity) : (cart)
$msg cart.checkout (customerId, paymentConfirmation) : (cart)
di:es:el editor
dsl here...
Change the name of the message say.hi or change the default value there, from "Harry" to "me", or something.
Then hit "Save" and play with it (hint: checkout the REST tab).
Note that even though you are not logged in, you can play with this! Cool, huh?
Your temporary "session" will expire in 5 minutes or so... if you mock it up, just refresh the page to start again.
To edit this topic and fully explore this, just create an account!
Use this !
Nah
We can add details like types later, but for now we have a simple cart API in the form of messages. The API will now insulate you from the external services you'll choose later for database, workflows etc. This API has an implicit REST form behind it and you can see that and also invoke it) if you click on the "REST" tab.
The state | form
The first thing needed is a state, somewhere to store this cart, so it survives html refreshes, can move from the client's desktop to the phone etc. Adding that functionality behind the API is very simple:
$when cart.get (customerId ?= "Joe")
=> diesel.memdb.get (collection="cart", id=customerId)
=> $if (document is undefined) diesel.memdb.upsert (
collection="cart",
document = {customerId : customerId, items : []},
id=customerId)
=> (cart = document)
.todo make this idempotent
$when cart.addItem (customerId ?= "Joe", sku ?="123", quantity ?= 5)
=> cart.get
=> (cart=cart+{items:{sku : "$sku", quantity : "$quantity"} })
=> diesel.memdb.upsert (collection="cart", document = cart, id=customerId)
di:es:el editor
dsl here...
Change the name of the message say.hi or change the default value there, from "Harry" to "me", or something.
Then hit "Save" and play with it (hint: checkout the REST tab).
Note that even though you are not logged in, you can play with this! Cool, huh?
Your temporary "session" will expire in 5 minutes or so... if you mock it up, just refresh the page to start again.
To edit this topic and fully explore this, just create an account!
Use this !
Nah
A few DB services are hosted and available here or you can use one of many external state services, now hidden behind your API.
Mocking APIs and services
If you'd rather add a mock for the cart API you defined, it's also very easy:
$mock cart.addItem (customerId ?= "Joe", sku ?="123", quantity ?= 5)
=> cart.get
=> (cart=cart+{items:{sku : "$sku", quantity : "$quantity"} })
$mock cart.get (customerId ?= "Joe") => (cart = {customerId : "Joe", items : []})
di:es:el editor
dsl here...
Change the name of the message say.hi or change the default value there, from "Harry" to "me", or something.
Then hit "Save" and play with it (hint: checkout the REST tab).
Note that even though you are not logged in, you can play with this! Cool, huh?
Your temporary "session" will expire in 5 minutes or so... if you mock it up, just refresh the page to start again.
To edit this topic and fully explore this, just create an account!
Use this !
Nah
Integration and mediation
Integrating systems and composing their functionality...
$msg catalog.getPrice (sku)
$msg cart.addItem (customerId ?= "Joe", sku, quantity)
$msg billing.charge (customerId >= "Joe", amount)
di:es:el editor
dsl here...
Change the name of the message say.hi or change the default value there, from "Harry" to "me", or something.
Then hit "Save" and play with it (hint: checkout the REST tab).
Note that even though you are not logged in, you can play with this! Cool, huh?
Your temporary "session" will expire in 5 minutes or so... if you mock it up, just refresh the page to start again.
To edit this topic and fully explore this, just create an account!
Use this !
Nah
APIs are often much less interesting than the stories they tell... or the stories you can create with them, i.e. systems, apps etc. The behaviour of these systems as a whole... that's where the value of the system is.
Testing microservices
$send say.hi (name = "Jane")
$expect (greeting contains "Jane")
di:es:el editor
dsl here...
Change the name of the message say.hi or change the default value there, from "Harry" to "me", or something.
Then hit "Save" and play with it (hint: checkout the REST tab).
Note that even though you are not logged in, you can play with this! Cool, huh?
Your temporary "session" will expire in 5 minutes or so... if you mock it up, just refresh the page to start again.
To edit this topic and fully explore this, just create an account!
Use this !
Nah
How do we specify our expectations about the value? How do we communicate it,
record it, share it, cooperate on it?
Use cases and user stories can turn into automated tests! (one that you can run and trace right now) (read more++)
Interested in simplifying microservices testing? ...
In the modern age, enterprises are transformed by microservices, APIs and reactive principles.
If you want to take a refreshing look at microservices requirements, acceptance and truly continuous testing, while fiddling with the architecture itself, start by creating a free account.