Doctolib offers doctors and hospitals a software solution with a full-range of services to improve the efficiency of their organization, provide their patients with a new high-end experience, grow their activity and develop their cooperation with other doctors.
In those slides, we will present how we connected old web and desktop softwares with our website to make the user feel he's using only one software.
https://www.youtube.com/watch?v=K-zHEcSPwi4&feature=youtu.be&t=10m
6. What we’re building
● A chrome extension that allow to exchange messages between
Doctolib and the PMS
● Three topics should be addressed:
○ Have buttons into each software to trigger actions in the other
○ Allow to switch the focus
○ Synchronise data
7.
8. Zipper
Actions
Temporality
Appointment booking
(online, by phone, update/cancellation)
1
Welcoming of the patient
(identity validation and waiting room management)
2
Rebook an appointment8
Billing6
Remote transmission7
Consultation: medical prescription5
Consultation: medical data seizure4
Medical and administrative records seizure with or
without insurance card
3
Messaging System
10. Background script
● The code that runs in chrome, not in a specific tab
● It is where we put all the “routing” and “logic” stuff
● It can do magic stuff using the chrome API, such as focusing a tab
11. Content script
● It is injected on a tab based on the URL
● Shares the context of the website
● Have access to the DOM, but not to the window object
12. Communication between components
● To communicate between Content Scripts and Background Scripts:
● Chrome messaging
● To communicate between the PMS and Content Scripts:
● window.postMessage
19. Context: The Case of Desktop Softwares
● Half of our customers are using a desktop software (the Internet did not exist in
1980)
● We need to connect them as well
● Most of desktop softwares are old and bloated, we need a simple API
21. Chrome Native Messaging
● API provided by Google Chrome and implemented by most browsers
● A way to exchange messages with a program installed on the user computer
● API similar to other message passing APIs provided by Chrome
● Chrome starts the native host on a separate process
● It communicates using standard input and standard output, sending and
receiving serialized JSON preceded by the length of the message (using a 32-bit
native integer)
22. Chrome Native
Messaging:
Sending a Message
● Connects to a native host
using connectNative
method
● Use the postMessage
method to send a message to
native host
23. Chrome Native
Messaging:
Receiving a Message
Adding listeners:
● on onMessageto handle
messages received from
native host
● on onDisconnectto catch
native host disconnection
24. Chrome Native
Messaging:
The Manifest File
● The file that defines the
configuration of the bridge
● Path defined by a registry key
on Windows, specific paths
on Linux and Mac
25. Packaging a Binary
With Pkg
● Node.JS binary packager
developed by Zeit
● Cross-compilation, easy to
install and use
26. Packaging a Binary With Pkg: How it Works
● Uses pre-compiled base node binaries with some patches applied
● Transforms javascript code into bytecode
● Snapshot filesystem: all files are embedded in the binary and prefixed by
/snapshot/, the program have access to the snapshot file system during runtime
● Targets:
○ node version
○ platform: windows, mac, linux or bsd
○ architecture: x64, x86, armv6 or armv7
○ all targets available in the pkg-fetch last release:
https://github.com/zeit/pkg-fetch/releases/tag/v2.5
27. Testing
● Using Jest for unit and integration tests
○ All the code is unit tested
○ Integration tests fakes the PMS and Chrome to assert an output when an
input is given
○ Installer tests runs installers on Windows to check that all files are
correctly deployed
● A lot of snapshot testing
