Google Drive API aansturen op basis van database logica

[BusterNL]

Hallo,

Ik weet niet of ik hier juist ben met mijn vraag, maar ik durf hem toch te stellen..

Ik heb een wens om Google Drive te gebruiken als opslagmedium, waarbij ik mappen cq. bestanden wil kunnen aanmaken verplaatsen en bestanden hierin uploaden op basis van logica in een on premise database.

Op zichzelf lijkt mij dit prima te doen door op basis van logica in deze database de Google API aan te kunnen sturen.

Is er iemand die hier een oplossing richting voor weet en mij eventueel hiermee op weg kan helpen ?

Ik hoor graag,

Groeten,

[Merethil]

Je zou Google drive gewoon als filesysteem kunnen mounten: https://www.ostechnix.com...ual-file-system-in-linux/

Kan je er gewoon naartoe schrijven als iedere andere folder, scheelt weer een proprietary connectie bouwen en onderhouden (want dat doet iemand al voor je), en mocht je er ooit een S3, Stack storage of whatever van willen maken dan kan je een andere service voor het mounten van de folders erin hangen en weer verdergaan.

[Matis]

Ik weet niet in welke programmeertaal je de koppeling tussen de database en Google Drive wilt maken.

Mocht dat PHP zijn, dan zou je eens kunnen kijken naar de uitbreiding bovenop FlySystem: https://github.com/nao-pon/flysystem-google-drive

[merauder]

Wat heel erg uitmaakt bij deze implementatie is naar welk account de aangemaakte files moeten.

Heb je een centraal account gekoppeld aan de applicatie, dan ben je er eigenlijk al door een API te machtigen, en de data daar heen te sturen. Als je files gemaakt door een user wilt opslaan op het account van de user, zul je weer uit moeten wijken naar een Oauth2 achtige implementatie.

[alex3305]

Onlangs hebben wij een soortgelijk iets gedaan en daar kwam een hele grote hobbel naar boven. Vanuit Google mag je maar een keer per twee seconden een nieuw bestand aanmaken op Drive. Aanmaken gebeurt ook al met uploaden van bestanden. Als je dus snel veel kleine bestanden wilt aanmaken, dan mag dat maar 30 keer per minuut. Aan die limiet zit je overigens al vrij snel. Ook in combinatie met de overhead van het opzetten van verbindingen, inlezen van bestanden, e.d.

Wij gebruikte het uiteindelijk als backup / off-site storage mechanisme en met collecties van gearchiveerde bestanden was dit prima. Met individuele bestanden hadden we echter te weinig tijd in de dag zitten om alles te kunnen synchroniseren.

Je zou dus beter naar S3 / bucket opslag kunnen kijken. Dit gaat bijvoorbeeld met Firebase en is waarschijnlijk beter geschikt. Maar dat ligt ook heel erg aan jouw use-case.

Synchronisatie deden wij overigens met Rclone. Die applicatie neemt al dit soort werk voor je uit handen.