As new applications of optimization require different access methods to solvers new technologies must be explored. The evolution in browser technology has lead to WebAssembly (WASM) this enables code written for what was once server/local application code to be compiled and then run in the browser on the client side. By taking a solver written in C/C++ and porting the interface to be usable in the browser we examine the utility of the interface and example formulations.

1. LP solver in the browser
Fabion Kauker
f.kauker@gmail.com
Part of this research was conducted at 3-GIS

2. The challenge
● Writing models requires a specific environment + language
● Once you have a model you want to make it data driven
● Many options between commercial and open source solvers
● Lots of choices for application architecture
● Many applications require client side data access
● Solvers and models are just one part of a solution
● User experience benefits from iteration and feedback
● Need to integrate with other systems
● Want to track the effectiveness of a model/approach
● Running on via the web has tradeoffs between performance and ease

3. A typical solver workflow
Input dataGenerate
Output
Parse dataSolve model
Formulate
model
Optimization
Application

4. Application architecture
Browser, App, Client, Server, Cloud

5. Options
1. Local Software
Formulation of model and solver done on your own device
2. Client Side Formulation
Client app make the model sent to server for solve
Client side translates model solution to output
3. API
Data to server side - Server side formulation and solve - Data out from
server
a. Cloud solver c. Containerization/Virtualization
b. Microservices d. Serverless
4. Data Science Platform (Jupyter et al.)
5. Other?

6. Local Software
Need to figure out how to distribute to users
Have to support different OS’s
Rely on user to manage data
Local machine can get locked up due to compute load
Specialized installation requirements
User environments differ and can lead to issues
High barrier to entry, download, install, configure etc
Commercial license per machine can be expensive

7. Client side formulation
Similar issues to local but you remove the need for solver software for users
Now you have to manage a solver infrastructure
Develop code to serialize and then send plus return models
Have to handle and turn model solution into output locally
Commercial licenses can be expensive, but now shared across user base
Still relying on user to input data and setup environment
Have to pay for hosting of compute

8. API
All business logic on server side behind API.
Requires that you send the data to the server side.
Not always feasible, size of data and privacy
concerns.
Requires more devops capability and/or knowledge
Can quickly iterate versions, user base just keeps
using
Cost for machine hosting can be expensive plus
commercial licenses

9. Data Science Platform
Strong traction from user base
Many libraries easily installable in
addition to core platform
Use a “programming” like environment
to create solutions
Can be used to make nice visualizations
to communicate results
Local, hosted, server or colab

10. What is WebAssembly (WASM)?
Lets you be OS agnostic.
Run like native application but in the browser
Use the emscripten toolchain
Native --> LLVM --> WebAssembly
Deliver as static file.
Use as a module in JS
Ref: https://developer.mozilla.org/en-US/docs/WebAssembly/Concepts
Ref: https://emscripten.org/

11. source: https://research.mozilla.org/webassembly/

12. Approach
Learnings
● Find an open source solver and try get it to compile using emscripten
● Create a application to show the functionality
● Deploy it
Gotcha
● Documentation exists but it can have gaps which you fall through
● Assumptions that you have some experience in the language you want to
compile
● Error reporting can be cryptic
● Still new, multi threading not fully supported

13. Comparison
Easy usage and
maintainability
(High)
Deployability
(High)
API WASM
Local DS
Platform
Client Side
Formulation

14. Demo
https://tranquil-dusk-58927.herokuapp.com/

15. Next Steps
Expose the core library to JS
Formulate models in JS via the WASM compiled C++ API
Run benchmarking
Try to compile COIN or SCIP
Build a demo use case

16. Questions

17. More about WASM & Application architecture
https://www.gurobi.com/wp-content/uploads/2018/12/Webinar-Application-Architec
tures-Slides.pdf
https://www.gurobi.com/resource/gurobi-optimization-application-demos/
https://maxbittker.com/making-sandspiel
https://www.tu-braunschweig.de/Medien-DB/ias/pubs/2019-dimva.pdf
https://github.com/fhk/link_src https://github.com/iodide-project/pyodide
https://tinyurl.com/lpsolvewasm
http://miplib.zib.de/download.html