Clean Architecture - How to avoid implementing use cases twice in different programming languages

[Stefan Bradl]

Hi,

how would you approach in the following scenario:

• The application has multiple client applications
• All clients work with the same database/server (C#)
• The clients are implemented in different programming languages
• Mobile client is implemented in JavaScript and uses a HTTP API to execute use cases on the server. 
• Desktop client is implemented in C# and can either execute the uses cases locally or on the server. 

Now there should be a web client (for normal desktop browsers). This is written in JavaScript but it should be able to execute use cases locally. So the use cases developed in C# cannot be reused but of course I don't wont to implement everything twice.

I really can't imagine a solution to this problem but maybe someone has had a similar problem or has any ideas to discuss?!

[Łukasz Duda]

Can both clients use the same server HTTP API?

[Caio Fernando Bertoldi Paes de Andrade]

I’ve heard Dropbox has written its core business rules in C++, so they can make bindings for Java (Android), Obj-C (iOS), C# (Web + Desktop), reusing the same core code on all platforms. I’m not sure you can reuse the same C++ code when trying to run on Javascript though.

Hope this helps,

Caio

--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discu...@googlegroups.com.
To post to this group, send email to clean-code...@googlegroups.com.
Visit this group at https://groups.google.com/group/clean-code-discussion.

[Stefan Bradl]

Technically the two clients could use the same HTTP API but that is not desired. The idea is that the hadware which runs the web client for normal browsers is much more powerful than the mobile clients and for the sake of responsiveness and to take some load from the server it should execute the use cases locally and only go to the server for database stuff.

Some sort of transpiling or generating the use cases from a formal description could be possible but looks like it would be a lot of work.

[Łukasz Duda]

Did you try measuring the load. Are you sure it is not the database doing most heavy work.
What do you mean by responsiveness?
Are the technologies fixed? Can you choose different?

[Stefan Bradl]

Yeah a lot of the heavy work is database stuff so maybe that's not the most interesting part.

With responsiveness I mean latency. It is possible that the clients are connected with a low mobile internet connection. So this can lead to high latencies even for small and fast use cases.

Technologies are mostly fixed. There are no real alternatives to JavaScript in the browser (Browser is fixed because nothing has to be installed on the clients). Developers are used to C# and nobody (including me) would want to use JavaScript on the server side as well. Even if we did we had the problem that the desktop client would be developed in C# and could not use the JavaScript use cases. So it's basically the same problem just the other way round.

--
The only way to go fast is to go well.
---

You received this message because you are subscribed to a topic in the Google Groups "Clean Code Discussion" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clean-code-discussion/-2cH6saGSkY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clean-code-discu...@googlegroups.com.

[Stefan Bradl]

Just had a look at DuoCode... fist impression was promising

Am Freitag, 27. Mai 2016 14:18:06 UTC+2 schrieb Stefan Bradl: