So is this a.. microservice? If not, what is?

<p>I&#39;m implementing something rather simple(a small service), and I&#39;d like to do it in Go. For both learning, but also because I think it&#39;s pretty efficient.</p> <p>It&#39;s a service fetching stock market data based on a query parameter, i.e. &#34;GOOGL&#34; for Alphabet Inc., and &#34;MSFT&#34; for Microsoft. </p> <p>It then consumes a REST endpoint from a provider which takes this query, by http.get.</p> <p>After that, the query should be stored in memory, and served on a REST endpoint which other parts of the whole application can consume. There is no need for persistence, hence no database level.</p> <p>Does this seem like good practice? Or awful, or just plain stupid?</p> <hr/>**评论：**<br/><br/>TheMerovius: <pre><blockquote> <p>Does this seem like good practice? Or awful, or just plain stupid?</p> </blockquote> <p>That depends a bit on… why. This is essentially a specialized <a href="https://memcached.org/" rel="nofollow">memcached</a> - if your environment already has one of those, why not just use that? Or use something like <a href="https://github.com/golang/groupcache" rel="nofollow">groupcache</a>, which would even alleviate the operational cost of an additional memcached instance.</p> <p>The main question, I guess, is what the &#34;other parts of the whole application&#34; are. If they are all the same language, then it would seem more sensible to build this as a library on top of groupcache. Even if they are <em>not</em> all the same language, the cost of maintaining this logic in multiple languages should still be pretty low.</p> <p>Honestly, I&#39;d just… not run this as a separate binary. I&#39;d just use memcached/groupcache. Unless you need to do significant processing on the data.</p></pre>cbll: <pre><p>It&#39;s a react native application which uses firebase for authentication. There&#39;s a Java service which basically interfaces with a broker(for actually buying/selling stocks), and then I&#39;d like another service for fetching and storing the stock market data. Of course, I could just add the logic in Java and set up a REST controller for handling it, but I like the idea of having different services that I can change as I wish without touching the &#34;core&#34; of the application, if that makes sense?</p></pre>TheMerovius: <pre><p>The thing is that, what you are describing, sounds like maybe a hundred lines of code or so in either language. There is operational overhead involved in running an extra service and for that little code, personally, I wouldn&#39;t be willing to pay that overhead.</p> <p>The value added (from my POV) of doing it in a separate service, is that then multiple instances of your other servers can share an in-memory cache - but that&#39;s literally what memcached or groupcache are there to solve and they would be much cheaper, as you don&#39;t have to write them first.</p> <p>(while we&#39;re at it: Why can&#39;t you just use a caching HTTP Proxy anyway?)</p></pre>cbll: <pre><p>The reason I&#39;m leaning towards it is:</p> <ol> <li><p>I want to learn Golang, and I learn it by using it</p></li> <li><p>Go is quite fast at reading from memory, and it would be a good test to see if it should be used for more complex services later on</p></li> <li><p>Either service might be completely killed or replaced at some point, dividing up the logic would make this very simple, whereas bad mistakes might be made if they were within the same webserver.</p></li> </ol> <p>How would a caching http proxy solve the problem? </p></pre>TheMerovius: <pre><blockquote> <p>How would a caching http proxy solve the problem?</p> </blockquote> <p>The process you described is</p> <ul> <li>$thing makes an HTTP Request fetching Data</li> <li>$thing stores the Response in memory</li> <li>$thing replies to HTTP Requests with the stored Data</li> </ul> <p>That&#39;s a cache. Strictly speaking, you haven&#39;t yet talked about what <em>triggers</em> the initial fetching, but even if you need something specific here, you can always just do a request to the cache at whatever trigger event you want. There might also be additional processing done, which I asked about above, which would make it more than a <em>pure</em> cache. But not that much more.</p> <p>Like, I&#39;m really trying to figure out what the advantages are you are trying to achieve here. Because I don&#39;t really see any; it seems like a solution (I want to use Go!) in search of a problem (Let&#39;s write this thing in Go, even though it would be much easier not to).</p> <p>In the end, I mean… Whatever floats your boat :) I&#39;m just saying, from what you explained so far, this would seem much better solved with a handful of lines of client-side Java and some existing service like memcached (you mentioned you are using Firebase, meaning you are using GCP, meaning there is a hosted offering) or a caching proxy. That may be, because you haven&#39;t described the complexity of a problem or it may be because of other circumstances I&#39;m oblivious to - but if someone on my team would come to me with the design as described, I would strongly object.</p></pre>cbll: <pre><p>Fair enough :)</p> <p>I coded the whole thing in like 45 minutes, though I have never made anything this complex in Go before. It was a breeze! I really enjoy Go, even though I know Java well, this would take 3-4 times as long to do in Java for me I think. </p></pre>shovelpost: <pre><p>So you are writing a small service in order to add some specific new functionality without affecting the already working legacy/core system. Not that it matters but yeah I would call that a microservice and Go happens to be a really good fit for this.</p></pre>cbll: <pre><p>Glad to hear, those were my thoughts exactly. It&#39;s just gonna run a minimal webserver with a single REST endpoint that queries some information that lives in-memory. And of course, a feature which consumes that from a provider. Relatively simply input/process/output.</p></pre>