This document discusses an assets-based front-end architecture that allows delivering the same codebase across multiple platforms including web, mobile web, native mobile apps, and desktop apps. It describes how infrastructure components like a service discovery registry and loading process allow a main project to independently load and communicate with embedded microservices. Contracts are used to define communication between projects, with events and requests allowing services to interact while maintaining independence. This approach significantly reduces the cost and effort of multi-platform development by supporting a single codebase.

1. 19.12.2019
Cross-platform
assets-based front-end architecture
React Kyiv

2. Oleksandr
Tserkovnyi
Front-end Architect in PMLAB
JS Fest Program Committee member
Consultant
Running half marathons

3. Micro Frontends in short
✤ Solution for decomposition
✤ Build time / Run time
✤ Build time: any, most popular npm libs
✤ Run time: Lazy Load or iFrame
✤ Solve: independent deploy/development, freshness of tech
stack, maintainability, testability, boundaries
✤ Only for web

4. Independent development
✤ Key winner in industry
✤ Business benefits: speed, delivery, hypothesis option
✤ Any tech stack
✤ Any development process
✤ etc.

5. Not only web
✤ Usually the same project is used by
✤ Desktop web
✤ Mobile web
✤ Native App iOS
✤ Native App Android
✤ Desktop app
✤ etc.

6. HTML/CSS/JS support
All of the platforms have a tool to render html/css/js within like – iframe, webview or directly.

7. Cost of delivery one feature for
many platforms?

8. Photo print builder
Ordinar eShop

9. High cost

10. Why is that so high?
✤ Teams have their own planning and it is almost impossible to fit
their schedule the same time you want to release.
✤ Different teams = different implementations = very error-prone.
✤ So you need to get capacity of all teams in the project, in our case it is
3-4 teams on 6-7 platforms.
✤ Plan testing, might be regression testing.
✤ Plan release of artifacts.
✤ You need to have a plan for the rollback.

11. ✤ What if we can deliver the same codebase for all of the
platforms?
✤ How much will it cost then?

12. Low cost

13. Why is it low?
✤ 1 team supports it
✤ 1 time effort
✤ 1 plan for release and rollback
✤ 1 test plan
✤ etc.

14. Introducing assets-based
architecture
Gives ability to integrate one codebase to all platforms, thus reduce the cost of development

15. assets-based architecture
✤ Good at:
✤ contracts are known
✤ contracts are changed rarely
✤ save same product look and feel
✤ very dynamic runtime
✤ Bad at:
✤ communication in between services
✤ very fast load (due to roundtrip for assets-manifest)
✤ when you need to fully save native UX

16. Shutterfly

17. Main purpose
Additional business value

18. Embedded lazy loaded service
Connected to the main project
Main project

19. Some dynamic items affect

20. Assets based service
✤ User does not need them right now
✤ They create additional business value
✤ Need to support identical look and feel
✤ Must consume directly and dynamically the same data
(token, language, etc.)

21. Infrastructure level

22. Infrastructure entities
✤ HOST
Any product implementing its own logic, wants to include a service.
Must contain a proxy server to communicate with Service discovery. Implements it via INTEGRATION_PREFIX
✤ HOST Proxy
Should have an endpoint, which serves as a proxy for all requests to Service discovery. This endpoint + service
name is INTEGRATION_PREFIX
✤ Service discovery (similar to microservices Kubernetes,
Consul, DNS)
✤ Persistent storage
… for Service discovery. Storage for saving information about registered services. Persistent in order to be
available without alive API (object storage).

23. Infrastructure level loading (easier)
Loading…
get `photos` service
find service registry endpoint
proxy to the endpoint
return static of the service
proxy statics of the service

24. Infrastructure level API calls (easier)
call for service’s API
find service registry endpoint
proxy to the endpoint proxy
proxy response back

25. INTEGRATION_PREFIX
✤ location.origin/{SD_PROXY}/service/{SERVICE_NAME}
✤ e.g.: https://www.shutterfly.com/service-discovery/
service/photos
✤ Is needed for service, to be able to reach its own API/
Static/* resolver.
✤ css/js files are replaced before put into the HOST

26. Service discovery
✤ Store information about services.
✤ Can register and deregister a service.
✤ Proxy requests.
✤ Gives information for HOST of how to use a service.

27. Service discovery API
Works as reverse proxy

28. Service discovery API GET /proxy
{
"corefront": {
"mobile_web": {
"in": {
"en": "http://corefront-mobile"
},
"com": {
"ru": "http://corefront-mobile",
"en": "http://corefront-mobile"
}
}
},
// …
// …
"photos": {
"mobile_web": {
"com": {
"en": "http://photos-fe.domain",
"ru": "http://photos-fe.domain"
}
},
"mobile_native_android": {
"com": {
"en": "http://photos-fe.domain"
}
},
"mobile_native_ios": {
"com": {
"en": "http://photos-fe.domain"
}
}
}
}

29. O(1)
✤ Proxy EVERY request
✤ Easy trick:
save roundtrip by update
proxy memory variable ONLY
on CRUD of /service
POST/PUT/DELETE
so then, any other NON
/service request will work O(1)
at this point

30. Infrastructure flow

31. Register in service discovery
When service is ready
POST /service
{
"serviceName": "corefront",
"proxyPass": “http://corefront-mobile”
}

32. GET /service/{NAME}
/service/corefront
HOST asks for service in SD

33. PROXY PASS to `service.proxyPass`
http://corefront-mobile
HOST proxied by SD

34. SERVICE returns
{
"corefront_file1.mobile.js": "/path/mobile/com/en/1.file.mobile.js",
"corefront_file2.mobile.js": "/path/mobile/com/en/2.file.mobile.js",
"corefront_file1.mobile.css": "/path/mobile/com/en/1.mobile.css"
}
assets-manifest.json

35. ✤ Never caches + ?date=${+(new Date())}
✤ Served on root call
✤ Preserves /platform/brand/language structure
assets-manifest.json

36. FROM assets-manifest.json
<script src=“/service-discovery/service/corefront/path/mobile/com/en/
1.file.mobile.js”></script>
<script src=“/service-discovery/service/corefront/path/mobile/com/en/
2.file.mobile.js”></script>
<link href="/service-discovery/service/corefront/path/mobile/com/en/
1.mobile.css" rel=“stylesheet” />
later on … HOST’s LOADER
requests files

37. Run time

38. Run time entities (already common)
✤ LOADER – Loads service and its dependencies.
✤ REGISTER – Register services.
✤ STATE – Internal state for all architecture purposes.
✤ SHELL – Main entry-point and orchestrator.
✤ ADAPTER
Bridge between implementations in order to provide proper communication.
For instance ADAPTER must be used when web service wants to communicate with Native APP.

39. Loading…
service library load a service
Run time (easier)
load a service
register a service
loading state
service loaded

40. Run time (easier)
start
fire CustomEvent
service:registered
with observable ref
notify ref
register the service
service is loaded
store loaded state
service is registered

41. Communication level
✤ CustomEvent vs Event vs Global namespace
✤ .observable(publish: Function)
✤ observable for listening
✤ publish for triggering (HOST provides to integrate its own
state management)
✤ .notify()
✤ ADAPTER, adapts calls for different platforms

42. Contracts are known and strict
✤ Architecture contracts
✤ Business contracts

43. Architecture contracts
✤ Handshake contracts
service:loaded
service:registered
✤ Dependency contracts (request:data)
user-token
language
base-url
render-container
proxy-prefix

44. Business contracts
✤ Anything specific, which you may require from the HOST.
✤ Examples:
✤ Page UI change from page to page
✤ Platform where we run the app
✤ Brand
✤ URLs/URL templates for other services to route to

45. request:modal
✤ Business only
modal:login
modal:deposit
confirm:delete-some-stuff
notification:you-have-limits-don't-you?

46. event
✤ Architecture events
service:initialize
service:render
service:destroy
✤ Business events
change:* (change:language) – here is just example
user:login
user:logout
modal:login:open
modal:login:close
notification:my-custom-action:show
notification:my-custom-action:hide
notification:my-custom-action:accept
confirm:my-custom-action:accept
confirm:my-custom-action:decline
change:* (change:user-data, change:user-balance, change:page:exact-event-id) – here is just example

47. CustomEvent example
const serviceLoadedEvent = new CustomEvent("service:loaded", {
detail: {
name: "corefront"
}
});
globalThis.dispatchEvent(serviceLoadedEvent)

48. request:data example
const languageData_REQUEST: DataRequest = {
type: "request:data",
scope: "photos",
id: "language"
};
observable.publish(languageData_REQUEST)

49. request:modal example
const modalRequest: ModalRequest = {
type: "request:modal",
scope: "photos",
id: "modal:login"
};
observable.publish(modalRequest)

50. event example
const changeLanguageEv_SUCCESS = {
type: "event",
scope: "photos",
id: "change:language",
payload: {
data: "LANG"
}
};
observable.notify(changeLanguageEv_SUCCESS)

51. callNative(service: string, msg: { [key: string]: any }) {
if (globalThis.eventScope.webkit !== undefined) {
if (globalThis.eventScope.webkit.messageHandlers[service] !== undefined) {
globalThis.eventScope.webkit
.messageHandlers[service].postMessage(msg);
}
} else {
globalThis.eventScope[service] && globalThis.eventScope[service]
.postMessage(JSON.stringify(msg));
}
}
ADAPTER. Hot to call native?

52. callNative(service: string, msg: { [key: string]: any }) {
if (globalThis.eventScope.webkit !== undefined) {
if (globalThis.eventScope.webkit.messageHandlers[service] !== undefined) {
globalThis.eventScope.webkit
.messageHandlers[service].postMessage(msg);
}
} else {
globalThis.eventScope[service] && globalThis.eventScope[service]
.postMessage(JSON.stringify(msg));
}
}
ADAPTER (easier)

53. PMLAB state
✤ Released for Mobile Web platform
✤ In progress of release for Mobile Web 2/Desktop Web 2
✤ In progress of release for Android
✤ In development for iOS

54. Next steps
✤ Debug tool
✤ Contracts validation
✤ Integration tests

55. Thanks!