<p>Hi.</p>
<p>I'm not sure if this is the appropriate place for asking this question. I'm somewhat new to Go but not to programming. I mainly write in C# which is somewhat easier than Go at the moment. </p>
<p>I'm trying to write a small project with a web end point (for an API) that will accept a text file with lots of lines and then insert that data into a mongodb. It's effectively a catalog of all the data on several systems in my environment.</p>
<p>I want to create a web end point as well in go http so that i can serve up requests for where a file lives given it's name.</p>
<p>So i was thinking that my project would need several packages besides the obvious ones like mgo but I'm having trouble with defining what that would be.</p>
<p>I wrote a simple program that reads data from a file and then adds it to the mongodb collection and a program that searches for the files and gives me the appropriate information about that file (size, owner, ctime, etc.)</p>
<p>But now I want to put an http front end on it so i can serve an API that will push the data to mongodb and then also pull it up via the same API.</p>
<p>Should I modify those existing programs to use net/http and listen on different ports?</p>
<p>Or </p>
<p>Should I create a new project that starts a single http server and then calls those packages and passes the data to those packages?</p>
<p>is there a better way? Are there any examples anyone can think of that I can use to learn the correct way to do this?</p>
<p>Thank you.</p>
<hr/>**评论：**<br/><br/>venju: <pre><p>If you already have written the logic it makes no sense to integrate http shit into those packages; keep that layer as is and call it from http handlers. You can add an http.HandlerFunc for each endpoint which calls your existing functions. If your existing functions take io.Reader and io.Writer params that would be very easy and simple.</p></pre>retinascan: <pre><p>Thanks. This is pretty much what I was thinking too. Have a new program that imports those packages and uses a handler to call them. It makes the most sense to me and allows me to do things like use the packages individually or via the http server. I just don't have any good examples of something like this to reference. </p></pre>venju: <pre><p>If you want interoperability with std library tools and other people's tools, sticking with std library interfaces (implementing or consuming them) will be your best bet.</p></pre>weberc2: <pre><p>I'm intrigued. Can you elaborate on the structure of your data in mongo? Is it basically a list with a bunch of flat records (with each record containing key/value pairs for owner, original location, ctime, and file contents)?</p></pre>retinascan: <pre><p>Yes. I've got a collection called "files" which stores metadata for every file. Imagine a backup of a filesystem. Prior to doing the backup, i do a "find" -printf and store that data. That data gets put into a document per line (so per file) that stores the metadata. Does that help?</p></pre>LadyDascalie: <pre><p>I'd go for composability. Id the programs you're using for the side tasks are already doing their jobs the way you want them to, I'd create a small api that handles calling those programs with the input you provide.</p></pre>dewey4iv: <pre><p>Hey! :) - I don't know if I have enough info to really answer this for you but here goes: If it were me - I'd probably just break out the pieces into sub-packages and leave everything in a single binary. No reason to jump to micro service arch for such a simple API. Also - I don't know how committed you are to MongoDB - but if you are ever planning on doing any sort of scaling I'd suggest RethinkDB as a replacement. Actually, I'd suggest RethinkDB regardless. Let me know if you have any other questions.</p></pre>allhatenocattle: <pre><p>Rethinkdb is not a good direction at this time.</p>
<p><a href="https://rethinkdb.com/blog/rethinkdb-shutdown/" rel="nofollow">https://rethinkdb.com/blog/rethinkdb-shutdown/</a></p></pre>retinascan: <pre><p>Thanks. I appreciate the info!</p></pre>thememedad: <pre><p>Why mongo? Use SQLite3</p></pre>retinascan: <pre><p>I'm inserting millions if not billions of documents. And I'm thinking of scalability as well.</p></pre>tscs37: <pre><p>SQLite3 does fine with a couple million documents.</p>
<p>A well maintained PostgreSQL node should handle a couple billion rows.</p>
<p>Throw in some slaves to get better read performance.</p>
<p>MongoDB is probably not the worst possible idea but SQL databases have atleast two orders of magnitude stronger consistency which reduces your client code.</p></pre>justinisrael: <pre><p>This is out of scope from the original question. It would be similar to suggesting the OP switch to drinking soda instead of coffee while coding because reasons. The question was about integrating existing business logic with an http front end. Not choice of database or beverage. </p></pre>lacion: <pre><p>why use anything else that what he wants to use?</p>
<p>there is nothing wrong in using whatever he chooses.</p></pre>thememedad: <pre><p><a href="https://www.reddit.com/r/programming/comments/3dvzsl/why_you_should_never_ever_ever_use_mongodb/" rel="nofollow">https://www.reddit.com/r/programming/comments/3dvzsl/why_you_should_never_ever_ever_use_mongodb/</a></p>
<p>IDK</p></pre>dewey4iv: <pre><p>+1 - I've had SO many nightmarish issues with MongoDB. Granted, this was usually when we would try to scale it out.</p></pre>retinascan: <pre><p>This is good information to have. Right now, i'm just prototyping the thing so i'm using mongo. I think that a nosql db is the right container for this type of use case. At least at the moment I do.</p></pre>metarx: <pre><p>Oh so treating mongo/nosql like a relational db produces unexpected relational db results...</p>
<p>You might as well tell me you expected redis to never lose your data too... </p>
<p>Nosql is not relational/transactional. And cannot be treated as such. Makes it not ideal for all use cases, and also requires you to think about storing your data differently. None of these are mongos fault. Their the fault of the person who implemented.</p></pre>
